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

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

[Hibou57 (Yannick Duchêne)]

Hello boys and girls,

There is no kind of binary mode vs text mode flags with Ada stream/
file IO, as it there are with C. And then, C files are not typed,
while Ada files/streams are, thus, this will not make any sense to
simply talk about binary I/O with Ada. So let simply talk about non-
text I/O from and to standard input/output.

When some people need this, what is the typical preferred to do so ?

Using a custom file type which rely on the OS ? (one for each OS if it
is to be built for multiple platforms)
Simply use characters with Text_IO and then do a character code
interpretation as if it was binary data ?
Other ways ?

The first way, seems the more formal, but requires more work, and
probably a lot of testing to ensure the custom file type
implementation does not contain any error.

The second way seems to be safer in some way (relies on a standard
package), but does not seems safe in the way nothing can ensure no
data will not be lost or modified (as it is primarily Text_IO).

If I missed something in the standard packages which allow this to be
done directly, I simply apologize for this topic.

Have a nice time all

Y.

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

[Jeffrey R. Carter]

Hibou57 (Yannick Duch�ne) wrote:
> 
> There is no kind of binary mode vs text mode flags with Ada stream/
> file IO, as it there are with C. And then, C files are not typed,
> while Ada files/streams are, thus, this will not make any sense to
> simply talk about binary I/O with Ada. So let simply talk about non-
> text I/O from and to standard input/output.
> 
> When some people need this, what is the typical preferred to do so ?

Package Ada.Text_IO.Text_Streams (ARM A.12.2) allows converting 
Ada.Text_IO.File_Type to Stream_Access and reading and writing them through the 
capabilities of streams. This allows converting standard input and output to 
Stream_Access, since Ada.Text_IO provides the functions Standard_Input and 
Standard_Output which return Ada.Text_IO.File_Type.

For general binary I/O, one can use Ada.Sequential_IO or Ada.Direct_IO 
instantiated with an appropriate type, or Ada.Streams.Stream_IO. For standard 
input and output, however, this can only work if you have a name for these files 
that you can use to open them, and such a name is platform-dependent. The only 
independent way to access these files is through streams and 
Ada.Text_IO.Text_Streams.

-- 
Jeff Carter
"Drown in a vat of whiskey. Death, where is thy sting?"
Never Give a Sucker an Even Break
106

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

[Hibou57 (Yannick Duchêne)]

On 25 oct, 00:57, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
wrote:
> Package Ada.Text_IO.Text_Streams (ARM A.12.2) allows converting
> Ada.Text_IO.File_Type to Stream_Access and reading and writing them through the
> capabilities of streams. This allows converting standard input and output to
> Stream_Access, since Ada.Text_IO provides the functions Standard_Input and
> Standard_Output which return Ada.Text_IO.File_Type.

So I was lucky to ask about it here

There is further more a note in ARM 12.2, which says (annotated
reference) :

> NOTES
> 6  35 The ability to obtain a stream for a text file allows
> Current_Input, Current_Output, and Current_Error to be processed
> with the functionality of streams, including the mixing of text and
> binary input-output, and the mixing of binary input-output for
> different types.
> 7  36 Performing operations on the stream associated with a text file
> does not affect the column, line, or page counts.

Now I feel I've already seen this in the past, but later forget

Thanks Jeffrey

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

[Hibou57 (Yannick Duchêne)]

On 24 oct, 23:57, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
wrote:
> Package Ada.Text_IO.Text_Streams (ARM A.12.2) allows converting
> Ada.Text_IO.File_Type to Stream_Access and reading and writing them through the
> capabilities of streams.
While this seems to work most of times, I meet a malfunction (data not
preserved) if the stream ends with a line-feed (a byte whose value is
10). When it is, this last byte seems to be dropped from the stream,
which cause troubles if the binary format is expecting it. This occurs
only when it exactly ends with this byte, and it is Ok if this byte is
followed by a byte whose value is 0 (as an example). It does not occur
when the stream ends with a byte whose value is that of the carriage-
return (13).

Finally, this does not really turn the stream into a binary stream,
and some interpretations remain.

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

[John B. Matthews]

In article 
<0d02cd9f-2cf1-48b6-a10f-6ea84427139d@k4g2000yqb.googlegroups.com>,
 Hibou57 (Yannick Duchêne) <yannick_duchene@yahoo.fr> wrote:

> On 24 oct, 23:57, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
> wrote:
> > Package Ada.Text_IO.Text_Streams (ARM A.12.2) allows converting
> > Ada.Text_IO.File_Type to Stream_Access and reading and writing them through 
> > the
> > capabilities of streams.
> While this seems to work most of times, I meet a malfunction (data 
> not preserved) if the stream ends with a line-feed (a byte whose 
> value is 10). When it is, this last byte seems to be dropped from the 
> stream, which cause troubles if the binary format is expecting it. 
> This occurs only when it exactly ends with this byte, and it is Ok if 
> this byte is followed by a byte whose value is 0 (as an example). It 
> does not occur when the stream ends with a byte whose value is that 
> of the carriage- return (13).
> 
> Finally, this does not really turn the stream into a binary stream, 
> and some interpretations remain.

I get the same effect. I don't know if it's the shell (bash) or OS (Mac) 
doing it. I suspect the former: End_Of_File turns True when a final 
linefeed remains to be read; the effect is absent with redirection. I'm 
vaguely uneasy using an exception for flow control, but this seems to 
copy the data unmolested:

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;
begin
   Stream_Ptr := Text_Streams.Stream(Current_Input);
   loop
      Character'Read(Stream_Ptr, C);
      Put(C);
   end loop;
exception
   when End_Error => null;
end Copy;

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

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

[Hibou57 (Yannick Duchêne)]

On 27 oct, 02:14, "John B. Matthews" <nos...@nospam.invalid> wrote:
> 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;
> begin
>    Stream_Ptr := Text_Streams.Stream(Current_Input);
>    loop
>       Character'Read(Stream_Ptr, C);
>       Put(C);
>    end loop;
> exception
>    when End_Error => null;
> end Copy;
>
> --
> John B. Matthews
> trashgod at gmail dot com
> <http://sites.google.com/site/drjohnbmatthews>

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).

May be this is finally really better to re-create a type to stand for
the standard input as binary, but what I do not like with this way, is
the possible lack of knowledge of some platforms, which is required
for implementations (For me, it will be OK for Windows, BSD, Linux,
but not the others... although in the mean time, I'm not sure I will
ever need it for other platforms).

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

[John B. Matthews]

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>