Another problem with stream reading.

Another problem with stream reading.

[Erik Sigra]

Now I have the program

with Ada;                   use Ada;
with Text_IO;               use Text_IO;
with Ada.Streams;           use Streams;
with Ada.Streams.Stream_IO; use Stream_IO;

procedure Streamtest is
   The_File : Stream_IO.File_Type;
begin
   Open (The_File, In_File, "data");
   declare
      The_Stream : Stream_Access := Stream (The_File);
      type Byte is range 0 .. 255;
      for Byte'Size use 8;
      B : Byte;
   begin
      while not End_Of_File (The_File) loop
         Byte'Read (The_Stream, B);
         Put_Line ("Read B = " & B'Img);
      end loop;
   end;
end Streamtest;


The data file contains
"����" (hexadecimal "ff fe fd fc") (decimal "255 254 253 252). The output of 
the program is:
Read B =  255
Read B =  253


The problem is that it reads 2 bytes instead of 1 and thus skips each second 
byte. Why?

Re: Another problem with stream reading.

[Dan Andreatta]

Erik Sigra <sigra@home.se> wrote in
news:mailman.1017082205.9199.comp.lang.ada@ada.eu.org: 

> procedure Streamtest is
>    The_File : Stream_IO.File_Type;
> begin
>    Open (The_File, In_File, "data");
>    declare
>       The_Stream : Stream_Access := Stream (The_File);
>       type Byte is range 0 .. 255;
>       for Byte'Size use 8;
>       B : Byte;
>    begin
>       while not End_Of_File (The_File) loop
>          Byte'Read (The_Stream, B);
>          Put_Line ("Read B = " & B'Img);
>       end loop;
>    end;
> end Streamtest;

Don't know exactly why, but is you modify:

type Byte is mod 256;

it works properly.

Dan

Re: Another problem with stream reading.

[Erik Sigra]

m�ndagen den 25 mars 2002 20.01 skrev du:
> Erik Sigra <sigra@home.se> wrote in
>
> news:mailman.1017082205.9199.comp.lang.ada@ada.eu.org:
> > procedure Streamtest is
> >    The_File : Stream_IO.File_Type;
> > begin
> >    Open (The_File, In_File, "data");
> >    declare
> >       The_Stream : Stream_Access := Stream (The_File);
> >       type Byte is range 0 .. 255;
> >       for Byte'Size use 8;
> >       B : Byte;
> >    begin
> >       while not End_Of_File (The_File) loop
> >          Byte'Read (The_Stream, B);
> >          Put_Line ("Read B = " & B'Img);
> >       end loop;
> >    end;
> > end Streamtest;
>
> Don't know exactly why, but is you modify:
>
> type Byte is mod 256;
>
> it works properly.

Yes it works here to, thanks!

Does anyone know what causes this behaviour? Is it specified or should I 
report it to the compiler maker?

Re: Another problem with stream reading.

[Jeffrey Carter]

Erik Sigra wrote:
> 
> m�ndagen den 25 mars 2002 20.01 skrev du:
> > Erik Sigra <sigra@home.se> wrote in
> >
> > news:mailman.1017082205.9199.comp.lang.ada@ada.eu.org:
> > > procedure Streamtest is
> > >    The_File : Stream_IO.File_Type;
> > > begin
> > >    Open (The_File, In_File, "data");
> > >    declare
> > >       The_Stream : Stream_Access := Stream (The_File);
> > >       type Byte is range 0 .. 255;
> > >       for Byte'Size use 8;
> > >       B : Byte;
> > >    begin
> > >       while not End_Of_File (The_File) loop
> > >          Byte'Read (The_Stream, B);
> > >          Put_Line ("Read B = " & B'Img);
> > >       end loop;
> > >    end;
> > > end Streamtest;
> >
> > Don't know exactly why, but is you modify:
> >
> > type Byte is mod 256;
> >
> > it works properly.
> 
> Yes it works here to, thanks!
> 
> Does anyone know what causes this behaviour? Is it specified or should I
> report it to the compiler maker?

Probably because "range 0 .. 255" gives Byte'Base'Size of 16 and you're
running it on a little-endian machine, while "mod 2 ** 8" gives
Byte'Base'Size of 8;

-- 
Jeffrey Carter

Re: Another problem with stream reading.

[Stephen Leake]

Erik Sigra <sigra@home.se> writes:

> m�ndagen den 25 mars 2002 20.01 skrev du:
> > Erik Sigra <sigra@home.se> wrote in
> >
> > news:mailman.1017082205.9199.comp.lang.ada@ada.eu.org:
> > > procedure Streamtest is
> > >    The_File : Stream_IO.File_Type;
> > > begin
> > >    Open (The_File, In_File, "data");
> > >    declare
> > >       The_Stream : Stream_Access := Stream (The_File);
> > >       type Byte is range 0 .. 255;
> > >       for Byte'Size use 8;
> > >       B : Byte;
> > >    begin
> > >       while not End_Of_File (The_File) loop
> > >          Byte'Read (The_Stream, B);
> > >          Put_Line ("Read B = " & B'Img);
> > >       end loop;
> > >    end;
> > > end Streamtest;
> >
> > Don't know exactly why, but is you modify:
> >
> > type Byte is mod 256;
> >
> > it works properly.
> 
> Yes it works here to, thanks!
> 
> Does anyone know what causes this behaviour? Is it specified or should I 
> report it to the compiler maker?

Stream_IO must read and write the base type of the object. For "type
Byte is range 0 .. 255", the base type is a signed integer, so it
takes 16 bits. for "type Byte is mod 256", the base type is 8 bits.

To see why Stream_IO must read and write the base type, consider:

declare
    A : Byte'base;
begin
    Byte'Write (The_Stream, A);
end;

It gets worse; some compilers choose a 16 bit base type for "type
Signed_Byte is -128 .. 127;", and they are compliant with the Ada
standard. So basically, Stream_IO is _not_ guaranteed to be compatible
between compilers.

-- 
-- Stephe

Re: Another problem with stream reading.

[Warren W. Gay VE3WWG]

Just shooting from the hip here, I think the problem is that
you gave the compiler an impossible assignment. By that, I
mean that you've declared type Byte to have integer range
0..255 and at the same time said its size has to be 8 bits.
There is no room for that range and a sign bit (since it is
integer here) to exist in 8 bits (you need 9). As a result
of lying to HAL, HAL decided to disregard your statement
"for Byte'Size use 8" and used 16 instead.

If you want signed numbers, you need to fix the range. If
you want unsigned numbers, then you need a modulo type.


Erik Sigra wrote:

> Now I have the program
> 
> with Ada;                   use Ada;
> with Text_IO;               use Text_IO;
> with Ada.Streams;           use Streams;
> with Ada.Streams.Stream_IO; use Stream_IO;
> 
> procedure Streamtest is
>    The_File : Stream_IO.File_Type;
> begin
>    Open (The_File, In_File, "data");
>    declare
>       The_Stream : Stream_Access := Stream (The_File);
>       type Byte is range 0 .. 255;
>       for Byte'Size use 8;
>       B : Byte;
>    begin
>       while not End_Of_File (The_File) loop
>          Byte'Read (The_Stream, B);
>          Put_Line ("Read B = " & B'Img);
>       end loop;
>    end;
> end Streamtest;
> 
> 
> The data file contains
> "����" (hexadecimal "ff fe fd fc") (decimal "255 254 253 252). The output of 
> the program is:
> Read B =  255
> Read B =  253
> 
> 
> The problem is that it reads 2 bytes instead of 1 and thus skips each second 
> byte. Why?
> 


-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Another problem with stream reading.

[Erik Sigra]

tisdagen den 26 mars 2002 18.54 skrev du:
> Just shooting from the hip here, I think the problem is that
> you gave the compiler an impossible assignment. By that, I
> mean that you've declared type Byte to have integer range
> 0..255 and at the same time said its size has to be 8 bits.
> There is no room for that range and a sign bit (since it is
> integer here) to exist in 8 bits (you need 9). As a result
> of lying to HAL, HAL decided to disregard your statement
> "for Byte'Size use 8" and used 16 instead.

If you look carefully at my code you can se that i did NOT write "Integer 
range", just "range". And there is certainly no need for a sign bit for the 
range 0 .. 255. If I lie to the compiler, it does certainly not disregard it. 
It complais loudly. If I for example say "for Byte'Size use 7;", it replies
"size for "Byte" too small, minimum allowed is 8"


> If you want signed numbers, you need to fix the range. If
> you want unsigned numbers, then you need a modulo type.

I should not need a modulo type for unsigned numbers. See "Programming in Ada 
95" by John Barnes, 2nd edition, page 552:

	"	For example we can specify the amount of storage to be allocated for
	objects of a type, for the storage pool of an access type and for the working
	storage of a task type. This is done by an attribute definition clause. Thus

		type Byte is range 0 .. 255;
		for Byte'Size use 8;

	indicates that objects of type Byte should occupy only 8 bits. The size of
	individual objects can also be specified."


> Erik Sigra wrote:
> > Now I have the program
> >
> > with Ada;                   use Ada;
> > with Text_IO;               use Text_IO;
> > with Ada.Streams;           use Streams;
> > with Ada.Streams.Stream_IO; use Stream_IO;
> >
> > procedure Streamtest is
> >    The_File : Stream_IO.File_Type;
> > begin
> >    Open (The_File, In_File, "data");
> >    declare
> >       The_Stream : Stream_Access := Stream (The_File);
> >       type Byte is range 0 .. 255;
> >       for Byte'Size use 8;
> >       B : Byte;
> >    begin
> >       while not End_Of_File (The_File) loop
> >          Byte'Read (The_Stream, B);
> >          Put_Line ("Read B = " & B'Img);
> >       end loop;
> >    end;
> > end Streamtest;
> >
> >
> > The data file contains
> > "����" (hexadecimal "ff fe fd fc") (decimal "255 254 253 252). The output
> > of the program is:
> > Read B =  255
> > Read B =  253
> >
> >
> > The problem is that it reads 2 bytes instead of 1 and thus skips each
> > second byte. Why?

Re: Another problem with stream reading.

[Warren W. Gay VE3WWG]

Erik Sigra wrote:

> tisdagen den 26 mars 2002 18.54 skrev du:
> 
>>Just shooting from the hip here, I think the problem is that
>>you gave the compiler an impossible assignment. By that, I
>>mean that you've declared type Byte to have integer range
>>0..255 and at the same time said its size has to be 8 bits.
>>There is no room for that range and a sign bit (since it is
>>integer here) to exist in 8 bits (you need 9). As a result
>>of lying to HAL, HAL decided to disregard your statement
>>"for Byte'Size use 8" and used 16 instead.
>>
> 
> If you look carefully at my code you can se that i did NOT write "Integer 
> range", just "range". And there is certainly no need for a sign bit for the 
> range 0 .. 255. If I lie to the compiler, it does certainly not disregard it. 
> It complais loudly. If I for example say "for Byte'Size use 7;", it replies
> "size for "Byte" too small, minimum allowed is 8"


Well, I did say that I was "shooting from the hip". I guess
I missed this time :-P

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Another problem with stream reading.

[Dan Andreatta]

Erik Sigra <sigra@home.se> wrote in
news:mailman.1017244142.7106.comp.lang.ada@ada.eu.org: 

> tisdagen den 26 mars 2002 18.54 skrev du:
>> Just shooting from the hip here, I think the problem is that
>> you gave the compiler an impossible assignment. By that, I
>> mean that you've declared type Byte to have integer range
>> 0..255 and at the same time said its size has to be 8 bits.
>> There is no room for that range and a sign bit (since it is
>> integer here) to exist in 8 bits (you need 9). As a result
>> of lying to HAL, HAL decided to disregard your statement "for
>> Byte'Size use 8" and used 16 instead. 
> 
> If you look carefully at my code you can se that i did NOT write
> "Integer range", just "range". And there is certainly no need for a
> sign bit for the range 0 .. 255. If I lie to the compiler, it does
> certainly not disregard it. It complais loudly. If I for example say
> "for Byte'Size use 7;", it replies "size for "Byte" too small, minimum
> allowed is 8" 
> 

You are right. If you try with Sequential_IO, everything works perfectly. 
I don't know why, but the size of the base type for your definition of byte 
is 16. I did some tests too, and I found: 

type Byte is range 0..255        'Size => 8        'Base'Size => 16
type Byte is range -128..127     'Size => 8        'Base'Size => 8
type Byte is mod 256             'Size => 8        'Base'Size => 8

(all with "for Byte'Size use 8 ;" )

Why this happen? I don't know! 

Dan

Re: Another problem with stream reading.

[Randy Brukardt]

Erik Sigra wrote in message ...
>If you look carefully at my code you can se that i did NOT write
"Integer
>range", just "range". And there is certainly no need for a sign bit for
the
>range 0 .. 255. If I lie to the compiler, it does certainly not
disregard it.
>It complais loudly. If I for example say "for Byte'Size use 7;", it
replies
>"size for "Byte" too small, minimum allowed is 8"

That's the form of a declaration for a signed integer type. And negative
values must be provided for the base type, read the RM!
http://www.adaic.org/standards/95lrm/html/RM-3-5-4.html, paragraph 9.

> I should not need a modulo type for unsigned numbers.

You (usually) don't. But streams always read and write the base type,
and that is always signed unless use use a modular type. And your
original question was about the behavior of streams.

It would be nice if Ada had real unsigned types with checking, etc., but
I brought that up repeatedly during the design of Ada 95, and there was
no support. And that has not changed, so don't expect it to change in
Ada 0y. So we have only modular types if we really need unsigned
behavior.

Janus/Ada, at least, will generate code for your type byte as if it is
unsigned (that has necessary for Ada 83, which had no unsigned types at
all), with all of the checking. But where the language requires the base
type (such as in streams), we have to use signed 16-bits.

The place this matters, of course, is for the largest unsigned type. If
you declare
            type Unsigned is range 0 .. (2**32)-1;
in Janus/Ada for Windows, you'll get an error, because there is no
signed base type large enough to fit it. That's unfortunate, given that
the code generator is able to generate the operations, but that is the
price of having a good language standard. (We could have, and probably
should have, implemented a pragma to let the compiler ignore the
language rules here -- that is explicitly allowed by the standard - see
"non-standard integer types" (paragraph 26 in the same RM section
referenced above) -- but we never had a business reason for doing so.
Besides, I hate pragmas. :-)

                    Randy Brukardt.

Re: Another problem with stream reading.

[David Bolen]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Janus/Ada, at least, will generate code for your type byte as if it is
> unsigned (that has necessary for Ada 83, which had no unsigned types at
> all), with all of the checking. But where the language requires the base
> type (such as in streams), we have to use signed 16-bits.
> 
> The place this matters, of course, is for the largest unsigned type. If
> you declare
>             type Unsigned is range 0 .. (2**32)-1;
> in Janus/Ada for Windows, you'll get an error, because there is no
> signed base type large enough to fit it.

How would you typically work around this, if you really wanted to be
working with 32-bit unsigned quantities in your code?  If there's no
signed base type large enough (sans 64-bit support presumably) would
you have to implement your own set of operations on, say, a data type
made out of two 16-bit values?

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

Re: Another problem with stream reading.

[tmoran]

> But streams always read and write the base type,
  Default streams.  If you write your own you can do whatever you please.

Re: Another problem with stream reading.

[Marin David Condic]

Unsigned integers for Ada0y might be interesting, but I'm not sure what you
would do with them that you can't already do with modular types. If you need
a 32 bit unsigned that doesn't have the base type problem, you can get that
with a modular type. Is it that one might want overflow & underflow rather
than wraparound semantics? If that's the case, I'd think it would be nice to
have numeric types that saturate as well.

One of Ada's strengths is that it can describe in detail the exact needs of
a given data type. Perhaps adding unsigned integers (and math types that
saturate) would add to that strength. Arguing that you can get there from
here by just doing blah blah blah is interesting, but not necessarily
compelling. Its always nice to have direct language support for a feature
that is likely to see a lot of use.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:ua4mt7p1nif778@corp.supernews.com...
>
> It would be nice if Ada had real unsigned types with checking, etc., but
> I brought that up repeatedly during the design of Ada 95, and there was
> no support. And that has not changed, so don't expect it to change in
> Ada 0y. So we have only modular types if we really need unsigned
> behavior.
>

Re: Another problem with stream reading.

[Randy Brukardt]

David Bolen wrote in message ...
>"Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> Janus/Ada, at least, will generate code for your type byte as if it
is
>> unsigned (that has necessary for Ada 83, which had no unsigned types
at
>> all), with all of the checking. But where the language requires the
base
>> type (such as in streams), we have to use signed 16-bits.
>>
>> The place this matters, of course, is for the largest unsigned type.
If
>> you declare
>>             type Unsigned is range 0 .. (2**32)-1;
>> in Janus/Ada for Windows, you'll get an error, because there is no
>> signed base type large enough to fit it.
>
>How would you typically work around this, if you really wanted to be
>working with 32-bit unsigned quantities in your code?  If there's no
>signed base type large enough (sans 64-bit support presumably) would
>you have to implement your own set of operations on, say, a data type
>made out of two 16-bit values?


Portably, I think you'd have to do something like that.

Another option would be to use a 32-bit modular type, and do overflow
checking explicitly. For instance, for "+", if the result is smaller
than either of the operands, you've overflowed. Doing that for "*" is
unpleasant (you pretty much have to emulate the multiply), but its easy
for all of the other operations. It would be easy to define a package
like that (that is essentially how the Janus/Ada compiler handles value
for code generation purposes).

A pragma or something to get to the code generator's DW type would
probably be the best solution for Janus/Ada, since that would use the
processor's carry flag to do the overflow check. But of course that
wouldn't be portable.

                Randy.

Re: Another problem with stream reading.

[Larry Kilgallen]

In article <a7vceg$lto$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> Unsigned integers for Ada0y might be interesting, but I'm not sure what you
> would do with them that you can't already do with modular types. If you need
> a 32 bit unsigned that doesn't have the base type problem, you can get that
> with a modular type. Is it that one might want overflow & underflow rather
> than wraparound semantics? If that's the case, I'd think it would be nice to
> have numeric types that saturate as well.
> 
> One of Ada's strengths is that it can describe in detail the exact needs of
> a given data type. Perhaps adding unsigned integers (and math types that
> saturate) would add to that strength. Arguing that you can get there from
> here by just doing blah blah blah is interesting, but not necessarily
> compelling. Its always nice to have direct language support for a feature
> that is likely to see a lot of use.

What would be compelling is real-world of experience of how useful the
blah blah blah version has been, or the experimental version of GNAT.

Re: Another problem with stream reading.

[Marin David Condic]

True. From experience with blah blah blah versions of saturated math, I
*know* this is useful in real world applications. However, I don't know how
*generally* useful it might be - just useful within certain problem domains.
(It has applications wherever you have some object with known limits that
cannot be exceeded - such as an actuator that has a fixed range of motion or
a graphics screen that has some fixed boundaries. Elsewhere? Only experience
could tell...)

The problem with things like saturated math or unsigned integers is that
without direct support in the compiler, your garden variety cobbled together
solution starts having some serious performance penalties. Not necessarily a
big deal in workstation apps, but usually a big deal for the folks that need
it the most. A modified version of GNAT? That's always a possibility that
could prove interesting - but who would do it? ACT won't unless one or more
of their customers starts asking for it and I certainly don't have the time
(or commercial need, at the moment) to go figure out how to do it myself.
Maybe there's enough GNAT users out there interested in it, but unless they
develop a group consensus on it, it isn't likely to make it into the
compiler.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:BM$h1dY1PyDK@eisner.encompasserve.org...
>
> What would be compelling is real-world of experience of how useful the
> blah blah blah version has been, or the experimental version of GNAT.