Re: Another problem with stream reading.

["Randy Brukardt" <randy@rrsoftware.com>]

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.