From: Hibou57 (Yannick Duchêne) on
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.
From: Jeffrey R. Carter on
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
From: Hibou57 (Yannick Duchêne) on
On 25 oct, 00:57, "Jeffrey R. Carter" <spam.jrcarter....(a)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
From: Hibou57 (Yannick Duchêne) on
On 24 oct, 23:57, "Jeffrey R. Carter" <spam.jrcarter....(a)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.
From: John B. Matthews on
In article
<0d02cd9f-2cf1-48b6-a10f-6ea84427139d(a)k4g2000yqb.googlegroups.com>,
Hibou57 (Yannick Duchêne) <yannick_duchene(a)yahoo.fr> wrote:

> On 24 oct, 23:57, "Jeffrey R. Carter" <spam.jrcarter....(a)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>