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.
>
>
>
>
next prev 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