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,XPRIO
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d2bc1c4ca7f04be6,start
X-Google-Attributes: gid103376,public
From: "Jeff Creem" <jcreem@atetola.mv.com>
Subject: GNAT bug or expectations problem with Text_Io.Text_Streams
Date: 2000/09/23
Message-ID: <8qjmp5$189$1@pyrite.mv.net>#1/1
X-Deja-AN: 673383387
X-Priority: 3
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Complaints-To: abuse@mv.com
X-Trace: pyrite.mv.net 969760357 1289 199.125.98.8 (24 Sep 2000 01:52:37 GMT)
Organization: MV Communications, Inc.
X-MSMail-Priority: Normal
NNTP-Posting-Date: 24 Sep 2000 01:52:37 GMT
Newsgroups: comp.lang.ada
Date: 2000-09-24T01:52:37+00:00
List-Id: <comp.lang.ada>

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.