From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d2bc1c4ca7f04be6 X-Google-Attributes: gid103376,public From: "David C. Hoos, Sr." Subject: Re: GNAT bug or expectations problem with Text_Io.Text_Streams Date: 2000/09/24 Message-ID: #1/1 X-Deja-AN: 673464656 References: <8qjmp5$189$1@pyrite.mv.net> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 969792031 154.15.11.180 (Sun, 24 Sep 2000 03:40:31 PDT) Organization: EarthLink Inc. -- http://www.EarthLink.net X-MSMail-Priority: Normal NNTP-Posting-Date: Sun, 24 Sep 2000 03:40:31 PDT Newsgroups: comp.lang.ada Date: 2000-09-24T00:00:00+00:00 List-Id: 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" 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. > > > >