comp.lang.ada
 help / color / mirror / Atom feed
From: "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com>
Subject: Re: GNAT bug or expectations problem with Text_Io.Text_Streams
Date: 2000/09/24
Date: 2000-09-24T00:00:00+00:00	[thread overview]
Message-ID: <zSkz5.18980$ks.783347@newsread1.prod.itd.earthlink.net> (raw)
In-Reply-To: 8qjmp5$189$1@pyrite.mv.net

For what it's worth, the observed condition is not what you described.

What _is_ obeserved is that whenever a byte of value 16#0A# is written to
the stream, a byte of value 16#0D# is "helpfully" added _before_ the
16#0A#.  Bytes of value 16#0D# are written without decoration.

That said, the observed behavior seems to me to violate RM A 12.2 (34),
viz.:
"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."

"Jeff Creem" <jcreem@atetola.mv.com> wrote in message
news:8qjmp5$189$1@pyrite.mv.net...
> Yes...I know ACT does not take bug reports from here so I will send one
once
> I get some concurrence that this is not a problem with my expectations.
>
> I just recently tried to create a file with a text header and binary data
> after..Looked like one way to do this was using Text_IO and then
> Text_IO.Text_Streams to get a stream access for the 'write calls
> later...While this compiles ok I find that when the 'writes write a byte
> value
> that would have meaning in a text stream I get problems.
>
> For example,  when a byte with 16#0D# is written to the stream it is
> followed
> autmatically by 16#0A#. (Running on Win 95) looks to me like text_io
> is still watching in the background and sees a CR so it sticks in a LF
which
> is
> not what I wanted.
>
> So, given that an alternate approach is to stay in stream_io space the
whole
> time and totally pass on text_io I will probably do that but is this a bug
> or
> an expectations problem. The LRM section on Text_Streams is pretty terse
but
> my feeling after reading this is that the compiler should not do this.
>
> Of course on a Unix box this particular "problem" would probably not
happen
> due to the end of line
> approach there...
>
> Code follows :
> with Ada.Text_Io;
> with Ada.Text_Io.Text_Streams;
>
> procedure Show_Improper_Stream_Use is
>
>   type My_Byte_Type is mod 2**8;
>   for My_Byte_Type'Size use 8;
>
>   Zero_Byte : My_Byte_Type := 0;
>
>   File : Ada.Text_Io.File_Type;
>
> begin
>   Ada.Text_Io.Create(
>     Name => "test_file1",
>     File => File);
>   Ada.Text_Io.Put_Line(
>     File => File,
>     Item => "Hello");
>
>   for My_Byte in My_Byte_Type'range loop
>     My_Byte_Type'Write(Ada.Text_Io.Text_Streams.Stream(File), Zero_Byte);
>     My_Byte_Type'Write(Ada.Text_Io.Text_Streams.Stream(File), Zero_Byte);
>
>
>     My_Byte_Type'Write(Ada.Text_Io.Text_Streams.Stream(File), My_Byte);
>   end loop;
>
>   Ada.Text_Io.Close(File);
>
> end Show_Improper_Stream_Use;
>
>
>
> Hex dump of first part of file:
>
> 00000000   48 65 6C 6C 6F 0D 0A 00  00 00 00 00 01 00 00 02 00 00 03 00 00
> 04 00 00   Hello...............
> 00000024   05 00 00 06 00 00 07 00  00 08 00 00 09 00 00 0D 0A 00 00 0B 00
> 00 0C 00   ....................
>
> ^----I don't think this should be here.
>
>
>
>










  parent reply	other threads:[~2000-09-24  0:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-23  0:00 GNAT bug or expectations problem with Text_Io.Text_Streams Jeff Creem
2000-09-24  0:00 ` Preben Randhol
2000-09-24  0:00   ` Preben Randhol
2000-09-24  0:00   ` David C. Hoos, Sr.
2000-09-24  0:00 ` Preben Randhol
2000-09-24  0:00 ` David C. Hoos, Sr. [this message]
2000-09-24  0:00   ` Preben Randhol
2000-09-24  2:23 ` Ted Dennison
2000-09-24  0:00   ` Jeff Creem
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox