GNAT bug or expectations problem with Text_Io.Text_Streams

GNAT bug or expectations problem with Text_Io.Text_Streams

[Jeff Creem]

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.

Re: GNAT bug or expectations problem with Text_Io.Text_Streams

[David C. Hoos, Sr.]

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

Re: GNAT bug or expectations problem with Text_Io.Text_Streams

[David C. Hoos, Sr.]

<snip>
> It is probably I that do not understand streams, but I don't understand
> why Gnat didn't complain that there is no My_Byte declared? Can somebody
> enlighten me on this, please?
>
My_Byte is declared in the loop statement, just as any other
defining_identifier is declared as part of the loop_parameter_specification.

> --
> Preben Randhol - Ph.D student - http://www.pvv.org/~randhol/
> "i too once thought that when proved wrong that i lost somehow"
>                                - i was hoping, alanis morisette
>

Re: GNAT bug or expectations problem with Text_Io.Text_Streams

[Preben Randhol]

On Sat, 23 Sep 2000 21:56:42 -0400, Jeff Creem wrote:
>
>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.

I'm running Linux and after compiling and running your program with Gnat
3.13p I get:

*** File: Source/Ada95/Example/Stream/test_file1
00000000 : 48 65 6C 6C 6F 0A 00 00-00 00 00 01 00 00 02 00 : Hello...........
00000001 : 00 03 00 00 04 00 00 05-00 00 06 00 00 07 00 00 : ................
00000002 : 08 00 00 09 00 00 0A 00-00 0B 00 00 0C 00 00 0D : ................
00000003 : 00 00 0E 00 00 0F 00 00-10 00 00 11 00 00 12 00 : ................
00000004 : 00 13 00 00 14 00 00 15-00 00 16 00 00 17 00 00 : ................
00000005 : 18 00 00 19 00 00 1A 00-00 1B 00 00 1C 00 00 1D : ................
00000006 : 00 00 1E 00 00 1F 00 00-20 00 00 21 00 00 22 00 : ........ ..!..".
00000007 : 00 23 00 00 24 00 00 25-00 00 26 00 00 27 00 00 : .#..$..%..&..'..
00000008 : 28 00 00 29 00 00 2A 00-00 2B 00 00 2C 00 00 2D : (..)..*..+..,..-
00000009 : 00 00 2E 00 00 2F 00 00-30 00 00 31 00 00 32 00 : ...../..0..1..2.
0000000A : 00 33 00 00 34 00 00 35-00 00 36 00 00 37 00 00 : .3..4..5..6..7..
0000000B : 38 00 00 39 00 00 3A 00-00 3B 00 00 3C 00 00 3D : 8..9..:..;..<..=
0000000C : 00 00 3E 00 00 3F 00 00-40 00 00 41 00 00 42 00 : ..>..?..@..A..B.
0000000D : 00 43 00 00 44 00 00 45-00 00 46 00 00 47 00 00 : .C..D..E..F..G..
0000000E : 48 00 00 49 00 00 4A 00-00 4B 00 00 4C 00 00 4D : H..I..J..K..L..M
0000000F : 00 00 4E 00 00 4F 00 00-50 00 00 51 00 00 52 00 : ..N..O..P..Q..R.
00000010 : 00 53 00 00 54 00 00 55-00 00 56 00 00 57 00 00 : .S..T..U..V..W..
00000011 : 58 00 00 59 00 00 5A 00-00 5B 00 00 5C 00 00 5D : X..Y..Z..[..\..]
00000012 : 00 00 5E 00 00 5F 00 00-60 00 00 61 00 00 62 00 : ..^.._..`..a..b.
00000013 : 00 63 00 00 64 00 00 65-00 00 66 00 00 67 00 00 : .c..d..e..f..g..
00000014 : 68 00 00 69 00 00 6A 00-00 6B 00 00 6C 00 00 6D : h..i..j..k..l..m
00000015 : 00 00 6E 00 00 6F 00 00-70 00 00 71 00 00 72 00 : ..n..o..p..q..r.
00000016 : 00 73 00 00 74 00 00 75-00 00 76 00 00 77 00 00 : .s..t..u..v..w..
00000017 : 78 00 00 79 00 00 7A 00-00 7B 00 00 7C 00 00 7D : x..y..z..{..|..}
00000018 : 00 00 7E 00 00 7F 00 00-80 00 00 81 00 00 82 00 : ..~..\x7f..........
00000019 : 00 83 00 00 84 00 00 85-00 00 86 00 00 87 00 00 : ................
0000001A : 88 00 00 89 00 00 8A 00-00 8B 00 00 8C 00 00 8D : ................
0000001B : 00 00 8E 00 00 8F 00 00-90 00 00 91 00 00 92 00 : ................
0000001C : 00 93 00 00 94 00 00 95-00 00 96 00 00 97 00 00 : ................
0000001D : 98 00 00 99 00 00 9A 00-00 9B 00 00 9C 00 00 9D : ................
0000001E : 00 00 9E 00 00 9F 00 00-A0 00 00 A1 00 00 A2 00 : ........�..�..�.
0000001F : 00 A3 00 00 A4 00 00 A5-00 00 A6 00 00 A7 00 00 : .�..�..�..�..�..
00000020 : A8 00 00 A9 00 00 AA 00-00 AB 00 00 AC 00 00 AD : �..�..�..�..�..�
00000021 : 00 00 AE 00 00 AF 00 00-B0 00 00 B1 00 00 B2 00 : ..�..�..�..�..�.
00000022 : 00 B3 00 00 B4 00 00 B5-00 00 B6 00 00 B7 00 00 : .�..�..�..�..�..
00000023 : B8 00 00 B9 00 00 BA 00-00 BB 00 00 BC 00 00 BD : �..�..�..�..�..�
00000024 : 00 00 BE 00 00 BF 00 00-C0 00 00 C1 00 00 C2 00 : ..�..�..�..�..�.
00000025 : 00 C3 00 00 C4 00 00 C5-00 00 C6 00 00 C7 00 00 : .�..�..�..�..�..
00000026 : C8 00 00 C9 00 00 CA 00-00 CB 00 00 CC 00 00 CD : �..�..�..�..�..�
00000027 : 00 00 CE 00 00 CF 00 00-D0 00 00 D1 00 00 D2 00 : ..�..�..�..�..�.
00000028 : 00 D3 00 00 D4 00 00 D5-00 00 D6 00 00 D7 00 00 : .�..�..�..�..�..
00000029 : D8 00 00 D9 00 00 DA 00-00 DB 00 00 DC 00 00 DD : �..�..�..�..�..�
0000002A : 00 00 DE 00 00 DF 00 00-E0 00 00 E1 00 00 E2 00 : ..�..�..�..�..�.
0000002B : 00 E3 00 00 E4 00 00 E5-00 00 E6 00 00 E7 00 00 : .�..�..�..�..�..
0000002C : E8 00 00 E9 00 00 EA 00-00 EB 00 00 EC 00 00 ED : �..�..�..�..�..�
0000002D : 00 00 EE 00 00 EF 00 00-F0 00 00 F1 00 00 F2 00 : ..�..�..�..�..�.
0000002E : 00 F3 00 00 F4 00 00 F5-00 00 F6 00 00 F7 00 00 : .�..�..�..�..�..
0000002F : F8 00 00 F9 00 00 FA 00-00 FB 00 00 FC 00 00 FD : �..�..�..�..�..�
00000030 : 00 00 FE 00 00 FF      -                        : ..�..�          

Displayed: 1 File.

To me it looks like you have some other bugs as well in your program?

-- 
Preben Randhol - Ph.D student - http://www.pvv.org/~randhol/
"i too once thought that when proved wrong that i lost somehow"
                               - i was hoping, alanis morisette

Re: GNAT bug or expectations problem with Text_Io.Text_Streams

[Preben Randhol]

On Sat, 23 Sep 2000 21:56:42 -0400, Jeff Creem wrote:
>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);
                                                               ^^^^^^^
                                                               Not
                                                               declared?

It is probably I that do not understand streams, but I don't understand
why Gnat didn't complain that there is no My_Byte declared? Can somebody
enlighten me on this, please?

-- 
Preben Randhol - Ph.D student - http://www.pvv.org/~randhol/
"i too once thought that when proved wrong that i lost somehow"
                               - i was hoping, alanis morisette

Re: GNAT bug or expectations problem with Text_Io.Text_Streams

[Preben Randhol]

On 24 Sep 2000 08:43:39 GMT, Preben Randhol wrote:
>>  for My_Byte in My_Byte_Type'range loop
        ^^^^^^^

        Arg I need new glases I think. Sorry I didn't see it here.


>>    My_Byte_Type'Write(Ada.Text_Io.Text_Streams.Stream(File), My_Byte);
>                                                               ^^^^^^^
>                                                               Not
>                                                               declared?

-- 
Preben Randhol - Ph.D student - http://www.pvv.org/~randhol/
"i too once thought that when proved wrong that i lost somehow"
                               - i was hoping, alanis morisette

Re: GNAT bug or expectations problem with Text_Io.Text_Streams

[Preben Randhol]

On Sun, 24 Sep 2000 10:40:31 GMT, David C. Hoos, Sr. wrote:
>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."


After looking in the Gnat 3.13p source code I found this:

a-textio.adb:

      --  This is the primitive Stream Write routine, used when a 
      --  Text_IO file is treated directly as a stream using
      --  Text_IO.Streams.Stream.

         procedure Write
         [...]

      --  Now we do the write. Since this is a text file, it is normally in
      --  text mode, but stream data must be written in binary mode, so we
      --  temporarily set binary mode for the write, resetting it after.
      --  These calls have no effect in a system (like Unix) where there is
      --  no distinction between text and binary files.

      set_binary_mode (fileno (File.Stream));

i-cstrea.ads:   procedure set_binary_mode (handle : int);
i-cstrea.ads:   pragma Import (C, set_binary_mode, "set_binary_mode");

-- 
Preben Randhol - Ph.D student - http://www.pvv.org/~randhol/
"i too once thought that when proved wrong that i lost somehow"
                               - i was hoping, alanis morisette

Re: GNAT bug or expectations problem with Text_Io.Text_Streams

[Jeff Creem]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:39CD67AE.7E56FD87@telepath.com...
> Jeff Creem wrote:
>
> > 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.
>
> Its possible that it is the underlying cygwin Unix-to-Windows conversion
code
> that is causing this problem.
>

Except that there has been no underlying cygwin code in Gnat since 3.10..It
has been mingw32 based
for a while since cygwin is pure GPL which can at times lead to license
issues for customers....

In any case after sleeping on it I have decided that it really is a bug so I
have submitted a bug report.
Thanks to everyone who responded.

Re: GNAT bug or expectations problem with Text_Io.Text_Streams

[Ted Dennison]

Jeff Creem wrote:

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

Its possible that it is the underlying cygwin Unix-to-Windows conversion code
that is causing this problem.

I had a similar problem with, of all things, tr. I had a file I was editing on a
Windows NT platform that needed to have Unix line termination on the target
machine or things wouldn't work right. So I figured I'd just use the cygwin "tr"
command to translate all the Windows CR line termination characters to the Unix
LF line termination character. The problem is, when it got written back out.
cygwin apparently translated them back for me. How helpful of it! :-(

BTW: For those who are curious, the solution to my problem was to set emacs to
use a Unix encoding with the sequence:
C-x RET f undecided-unix

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591