Re: Preferred way to do binray I/O on standard input/output stream

["John B. Matthews" <nospam@nospam.invalid>]

In article 
<a558f6b4-8f4c-459d-8706-4eb8125dae1e@w19g2000yqk.googlegroups.com>,
 Hibou57 (Yannick Duchêne) <yannick_duchene@yahoo.fr> wrote:

> The trouble with this, is that this force a look-ahead : an item
> must be read to know if an item is available, and this can lead
> into numerous logical traps (I prefer to keep distinct the action
> of reading and testing availability of data).

Ah, I see your point. I recall this problem going back to the days of 
UCSD Pascal, which distinguished between interactive and text type files 
for this very reason. My use is to allow command line utilities to read 
from standard input if no file name is supplied. For me, the data stream  
invariably arrives via redirection or a pipe, so the problem does not 
arise. For interactive programming, I typically use GtkAda.

This variation of Copy makes it easier to see what's happening. 
Prefacing the loop with the End_Of_File predicate exposes the problem 
for files with a terminal LF. If running interactively, control-D exits:

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Text_IO.Text_Streams;

procedure Copy is
   Stream_Ptr : Text_Streams.Stream_Access;
   C : Character;

   function Hex(C : Character) return String is
      H : constant String := "0123456789ABCDEF";
      B : Natural := Character'Pos(C);
      S : String(1 .. 4);
   begin
      S(1) := '[';
      S(2) := H(B / 16 + 1);
      S(3) := H(B mod 16 + 1);
      S(4) := ']';
      return S;
   end Hex;

begin
   Stream_Ptr := Text_Streams.Stream(Current_Input);
-- while not End_Of_File loop
   loop
      Character'Read(Stream_Ptr, C);
      Put(Hex(C));
   end loop;
exception
   when End_Error => null;
end Copy;

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>