Re: Size of 0..255 is not 8 bits?

Re: Size of 0..255 is not 8 bits?

[Matthew Heaney]

In article <355A436E.11F76529@cl.cam.ac.uk>, Markus Kuhn
<Markus.Kuhn@cl.cam.ac.uk> wrote:

(start of quote)
   type Value is range 0..255;
   for Value'Size use 8;

   V: Value;

begin
   for X in 1..5 loop
      Value'Read(Stream(Standard_Input), V);
      Put(Integer(V));
      New_Line;
   end loop;
end Strange2;
(end of quote)

Value'Base has to be implemented with a least 9 bits, because a base type
has to be symmetric about zero (the range of Value'Base is at least -255 ..
255).  Better is to throw a size clause on your object:

V : Value;
for V'Size use 8;

But I don't know if that will solve your problem.

(start of quote)
Did I missunderstand something and is S'Size not usable for enforcing
the number of bits allocated for a type?
Is 0..255 a type for signed 16-bit arithmetic and not a type for
(as I had naturally assumed) 8-bit unsigned arithmetic?
Do I have to use Unsigned_8 instead if I want to have a guarantee
to get an 8-bit word (which doesn't provide arithmetic overflow
checks)?
(end of quote)

Again, this may have something to do with Value'Base requiring a minimum of
9 bits to implement.  The RM encourages implementors to use the minimum
storage size required for a type, and here, that's 16 bits, as you've
confirmed.

You could try 

 type Value is range -128 .. 127;
or
type Value is new Interfaces.Integer_8;
(same as above)
or
type Value is mod 8;
or
type Value is new Interfaces.Unsigned_8;
(same as above)

How is Interfaces.Integer_8 implemented?  Probably as
   type Integer_8 is range -128 .. 127;

Throw a size clause on your object V, and see what that does.

Putting a size clause on a type is pretty misleading.  The base range of
the type

type Value is range 0 .. 255; 

definately requires 9 bits, so allowing the size clause

for Value'Size use 8;

is kind of confusing.

In fact, a variation of this very problem appears in the AARM 13.3 (55.k). 
As explained in AARM 13.3 (55.n, 55.o), the "correct" way to handle this is
to declare the object as having a size clause.  

I'm pretty sure that's the answer: put a size clause on the object, not the
type.

Size of 0..255 is not 8 bits?

[Markus Kuhn]

Gnat-3.10p on Linux reads 2 bytes from a stream for an object of
type range 0..255 that was forced with a 'Size representation clause
to be 8 bits long.

Example:

-----------------------------------------------------------------
with Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO;
use Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO;

procedure Strange2 is

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

   V: Value;

begin
   for X in 1..5 loop
      Value'Read(Stream(Standard_Input), V);
      Put(Integer(V));
      New_Line;
   end loop;
end Strange2;
-----------------------------------------------------------------

$ echo ABCDEFGHIJKLMNOP | ./strange2 
         65
         67
         69
         71
         73


Did I missunderstand something and is S'Size not usable for enforcing
the number of bits allocated for a type?
Is 0..255 a type for signed 16-bit arithmetic and not a type for
(as I had naturally assumed) 8-bit unsigned arithmetic?
Do I have to use Unsigned_8 instead if I want to have a guarantee
to get an 8-bit word (which doesn't provide arithmetic overflow
checks)?

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Size of 0..255 is not 8 bits?

[Tom Moran]

What compiler?  There was a previous discussion about using a base
type, and size, larger than you might have expected.  

Re: Size of 0..255 is not 8 bits?

[Markus Kuhn]

Matthew Heaney wrote:
> Better is to throw a size clause on your object:
>
> type Value is range 0..255;
> V : Value;
> for V'Size use 8;

This did not change anything, V is still a 16-bit integer. I get
no difference whether the 'Size clause is for the type, the object,
both or none at all. Only

  type Value is mod 2**8;

gave me really an 8-bit unsigned integer variable.

> Throw a size clause on your object V, and see what that does.

Nothing.

I see, why 0..255 requires an at least  9-bit signed type, but
I am somewhat disappointed that neither the type'Size nor the
object'Size clause gives me a compiler warning that this is not
an 8-bit type.

So all this IMHO means that either gnat-3.10p contains an error
here or that John Barnes wrote nonsense in "Programming in Ada95",
1996, p. 526, where he writes "Thus

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

indicates that objects of the type Byte should occupy only 8 bits."

The weirdest effect is that if I read the file content "ABCDEFGH...",
I get only every second byte (65 67 69 ...) with Value'Read,
and not as I would have expected a sequence of 16-bit values
(65+66*2**8 67+68*2**8 ...) or constraint errors.

Any guru insight?

Other question: If the rest of a stream is too short for a
T'Read to succeed, what is supposed to happen? Constraint error?
The ARM doesn't say much on this subject.

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Size of 0..255 is not 8 bits?

[John McCabe]

Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote:

>Other question: If the rest of a stream is too short for a
>T'Read to succeed, what is supposed to happen? Constraint error?

You should get an "End_Error".

-- 
Best Regards
John McCabe

=====================================================================
Any opinions expressed are mine and based on my own experience. They
  should in no way be taken as the opinion of anyone I am currently
     working with, or of the company I am currently working for.
       If you have a problem with anything I say, SPEAK TO ME!
                (remove "nospam." to reply by e-mail)
=====================================================================

Re: Size of 0..255 is not 8 bits?

[Robert Dewar]

Matthew says

<<type Value is range 0 .. 255;

definately requires 9 bits, so allowing the size clause

for Value'Size use 8;

is kind of confusing.
>>


More serious confusion on size! No, this is not "kind of confusing". It
is perfectly reasonable, and very useful to write

  type x is range 0 .. 3;
  for x'size use 2;

The size clause has nothing to do with the base values, which is where Matthew
is getting confused. The above size clause works just fine in conjunction
with pragma Pack, on an array, where you will get an array of 2 bit values
as expected.

The important thing to realize is that specifying a size for a type in
Ada 95 does not necesarily affect the size of objects of that type except
in the packed case. 

Howver, in a reasonable Ada 95 compiler, it is indeed the case that the
size clause for Value above should result in objects of type Value being
stored in 8 bits by default.

Re: Size of 0..255 is not 8 bits?

[Robert Dewar]

Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote:

>Other question: If the rest of a stream is too short for a
>T'Read to succeed, what is supposed to happen? Constraint error?


Quoting the GNAT sources ... (s-stratt.adb)

   Err : exception renames Ada.IO_Exceptions.End_Error;
   --  Exception raised if insufficient data read (note that the RM implies
   --  that Data_Error might be the appropriate choice, but AI195-00132
   --  decides with a binding interpretation that End_Error is preferred).

Note that it is a little odd that streams (which have nothing to do with
IO) should raise an exception in Ada.IO_Exceptions, but the AI is clear
as to the preference for this.

Re: Size of 0..255 is not 8 bits?

[Robert Dewar]

<<This did not change anything, V is still a 16-bit integer. I get
no difference whether the 'Size clause is for the type, the object,
both or none at all. Only
>>


It is indeed a bug in a compiler if a Size clause for an object does not
result in the object tkaing the indicated nnumber of bits. But perhaps
you had better post the EXACT code that leads you to that conclusion.

Size causes so much confusion among those who don't understand it clearly,
that I  often find that when the code is displayed it does not at all
correspond to the original decsription.
does not 
clearly correspond to the description or conclusions that have
been published!

It is interesting that a significant portion of our support activities
revolves around issues with size and other representation clauses,
where programmers have written implementation dependent code and
not realized that they were doing so. We spend quite a bit of time
explaining the problem and helping to figure out how to most easily
fix it.

Robert Dewar
Ada Core Technologies

Re: Size of 0..255 is not 8 bits?

[Simon Pilgrim]

Robert Dewar wrote:
> 
> <<This did not change anything, V is still a 16-bit integer. I get
> no difference whether the 'Size clause is for the type, the object,
> both or none at all. Only
> >>
> 
> It is indeed a bug in a compiler if a Size clause for an object does not
> result in the object tkaing the indicated nnumber of bits. But perhaps
> you had better post the EXACT code that leads you to that conclusion.

After reading one of your posts in another thread on 'size, I took
Markus' code and added some lines to display the sizes:

----------------------------------
   with Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO;
   use  Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO;

   procedure Strange2 is
      type ValueType is range 0..255;
      for ValueType'Object_Size use 8;
      V: ValueType;
   begin
      Put ("          ValueType'last:");
      Put (Integer(ValueType'last));
      New_line;
      Put ("          ValueType'size:");
      Put (Integer(ValueType'size));
      New_line;
      Put ("   ValueType'object_size:");
      Put (Integer(ValueType'object_size));
      New_line;
      Put ("                  V'size:");
      Put (Integer(V'size));
      New_line;

      for X in 1..5 loop
         ValueType'Read(Stream(Standard_Input), V);
         Put(Integer(V));
      end loop;
   end Strange2;
----------------------------------

I compiled and ran this with GNAT 3.10p on WinNT4 and got the following:

 >echo ABCDEFGHIJKLMNOP | ./strange2
          ValueType'last:        255
          ValueType'size:          8
   ValueType'object_size:          8
                  V'size:          8
         65         67         69         71         73
This appears to be reading 8 bit chunks from the stream, but every other
byte.

If I changed the range of ValueType to 0..127 and rebuilt, I got the
following:

  >echo ABCDEFGHIJKLMNOP | ./strange2
          ValueType'last:        127
          ValueType'size:          7
   ValueType'object_size:          8
                  V'size:          8
         65         66         67         68         69
This works as I expect.

Regards,

Simon Pilgrim

Re: Size of 0..255 is not 8 bits?

[Samuel T. Harris]

Markus Kuhn wrote:
> 
> Robert Dewar wrote:
> > It is indeed a bug in a compiler if a Size clause for an object does not
> > result in the object tkaing the indicated nnumber of bits. But perhaps
> > you had better post the EXACT code that leads you to that conclusion.
> 
> Ok, here comes the exact code and the execution result of what
> confuses me.
> 
> Environment: gnat-3.10p-i386-linux-bin
>              Linux kernel 2.0.29
>              libc.so.5.3.12.
> 
> ---------------------------------------------------------------------
> with Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO;
> use  Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO;
> 
> procedure Strange2 is
> 
>    type Value is range 0..255;
>    for Value'Size use 8;
> 
>    V: Value;
>    for V'Size use 8;
> 
> begin
>    for X in 1..5 loop
>       Value'Read(Stream(Standard_Input), V);
>       Put(Integer(V));
>       New_Line;
>    end loop;
> end Strange2;
> ---------------------------------------------------------------------
> $ echo "ABCDEFGHIJK" | ./strange2
>          65
>          67
>          69
>          71
>          73
> ---------------------------------------------------------------------
> PROBLEM: Although I have been very explicit about that I want V
> to be 8 bits large, and although GNAT generated no errors or
> warnings when compiling the above, Value'Read clearly eats 16-bit
> chunks per call, but stores only the first 8 bits, which I consider
> highly surprising.
> I would have expected to see either an output like
>          65
>          66
>          67
>          68
>          69
> or to get a compiler error message telling me that the "use 8"
> representation clause for "range 0..255" cannot be used.
> ---------------------------------------------------------------------

This really isn't a 'size issue. The size of V is 8 bits.
If the stream was reading 16 bits and shoving all of them into
variable V then I'd expect a constraint_error!

The ARM states in section 13.13.2
Stream-Oriented Attributes:

For every subtype S of a specific type T, the follow attributes
are defined.

S'Write    S'Write denotes a procedure witht he following
           specification:

           procedure S'Write (Stream : access
                              Ada.Streams.Root_Stream_Type'Class;
                              Item   : in T)

           S'Write writes the value of Item to Stream.

S'Read     S'Read denotes a procedure with the following
           specification:

           procedure S'Read (Stream : access
                             Ada.Streams.Root_Stream_Type'Class;
                             Item : out T)

           S'Read reads the value of Item from Stream.

It is vitally important to note that 'Read and 'Write DO NOT
operate on Items of subtype S, but on type T. In the above code,
Value is the first subtype S of a base type T. Because it is
a signed integer type, it must be reflexive around 0. This means
the base type T MUST larger than 8 bits. Indeed, most compilers
are limited to machine supported sizes (means byte sized things)
so the base type T is 16 bits which is the next largest available
supported signed integer type. The Read and Write operations are
all occuring on objects of type T (16 bits) and not type S (Value
which is 8 bits).

So the stream is reading 16 bits into an Item of type T
which is 16 bits. Since the variable V is used in the call,
I'd expect some sort of type conversion to accomodate
the actual representation of the variable. It appears GNAT
is simply fitting the lower 8 bits into the 8 bit sized
variable V. This is unexpected behavior. I expect such a
type conversion and assignment of the out varible to
raise a constraint error since the 16 bit values are
outside of the range of V.

> 
> This looks like a GNAT 3.10p bug to me. If I replace "range 0..255"
> with "mod 256", then everything works nicely.

Of course it does. Modulo types are unsigned. They do not reflect
about 0. The base type does not need to be larger to accomodate
the extra values. A mod 256 type fits naturally into 8-bits so
both type Value and its base type T are 8 bits. The 'Read and 'Write
operations still operation on items of the base type T, which is
of 8 bits so everything works as expected. This goes to show
modulo types are the preferred types to use for such representations.

> 
> Markus
> 
> --
> Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
> email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

-- 
Samuel T. Harris, Principal Engineer
Raytheon Training Incorporated
"If you can make it, We can fake it!"

Re: Size of 0..255 is not 8 bits?

[Tucker Taft]

As was finally pointed out, this is an issue with the
stream representation of a subtype (i.e. what S'Read and S'Write do), 
not a problem with S'Size or with the size of objects.

As defined by the RM, S'Base'Size is what matters for S'Read and
S'Write, not S'Size.  This is probably a mistake, since S'Base'Size
is not necessarily portable, nor quite what is wanted.  We are
currently discussing in the "Ada Rapporteur Group" (ARG) making
a language change in this area.

One possible change would be to make the stream representation 
for a scalar type use the smallest number of stream elements
per item needed to include the range of the *first* subtype,
rather than the *base* subtype of the type.  This means that
certain values that are within the base range of the type might
not be writable with 'Write, but that seems better than the
current situation where the stream representation is non-portable,
and often non-intuitive.

As this example points out, it will be important to decide what 
happens with signed integer types whose first subtype has no negative 
values.  Probably the representation will be based on the value of
S'Size, which in a case like this, is clearly defined to be 8.
Presuming the size of a stream element is 8, then a scalar type whose
first subtype has 'Size of 8 would use just one stream element per
item.

In any case, this is all just speculation at this point, because the
ARG hasn't agreed on how to resolve this issue, or whether to propose
any language change at all.  However, this news thread indicates
that this problem is important to solve sooner rather than later.

-Tucker Taft  stt@inmet.com

Re: Size of 0..255 is not 8 bits?

[Joe Gwinn]

In article <dewar.895191407@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> Size causes so much confusion among those who don't understand it clearly,
> that I  often find that when the code is displayed it does not at all
> correspond to the original decsription.
> does not 
> clearly correspond to the description or conclusions that have
> been published!
> 
> It is interesting that a significant portion of our support activities
> revolves around issues with size and other representation clauses,
> where programmers have written implementation dependent code and
> not realized that they were doing so. We spend quite a bit of time
> explaining the problem and helping to figure out how to most easily
> fix it.

If the same problems and misunderstandings keep arising, perhaps this is a
good area to write some FAQ items about.  

Joe Gwinn

Re: Size of 0..255 is not 8 bits?

[Markus Kuhn]

Robert Dewar wrote:
> It is indeed a bug in a compiler if a Size clause for an object does not
> result in the object tkaing the indicated nnumber of bits. But perhaps
> you had better post the EXACT code that leads you to that conclusion.

Ok, here comes the exact code and the execution result of what
confuses me.

Environment: gnat-3.10p-i386-linux-bin
             Linux kernel 2.0.29
             libc.so.5.3.12.

---------------------------------------------------------------------
with Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO;
use  Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO;

procedure Strange2 is

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

   V: Value;
   for V'Size use 8;

begin
   for X in 1..5 loop
      Value'Read(Stream(Standard_Input), V);
      Put(Integer(V));
      New_Line;
   end loop;
end Strange2;
---------------------------------------------------------------------
$ echo "ABCDEFGHIJK" | ./strange2
         65
         67
         69
         71
         73
---------------------------------------------------------------------
PROBLEM: Although I have been very explicit about that I want V
to be 8 bits large, and although GNAT generated no errors or
warnings when compiling the above, Value'Read clearly eats 16-bit
chunks per call, but stores only the first 8 bits, which I consider
highly surprising.
I would have expected to see either an output like
         65
         66
         67
         68
         69
or to get a compiler error message telling me that the "use 8"
representation clause for "range 0..255" cannot be used. 
---------------------------------------------------------------------


And here is a related problem if I use streams on range 0..255
Arrays:

---------------------------------------------------------------------
with Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO;
use  Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO;

procedure Strange3 is

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

   type Value_Array is array(1..5) of Value;
   for Value_Array'Component_Size use 8;
   pragma Pack(Value_Array);

   VA: Value_Array;

begin
   Put(Value_Array'Size);
   Value_Array'Read(Stream(Standard_Input), VA);
   Put_Line("Read Success");
   for X in 1..5 loop
      Put(Integer(VA(X)));
      New_Line;
   end loop;
end Strange3;
---------------------------------------------------------------------
$ echo "ABCDEFGHIJK" | ./strange2
         40

raised CONSTRAINT_ERROR
---------------------------------------------------------------------
PROBLEM: Why do I get a CONSTRAINT_ERROR here?
---------------------------------------------------------------------

This looks like a GNAT 3.10p bug to me. If I replace "range 0..255"
with "mod 256", then everything works nicely.

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Size of 0..255 is not 8 bits?

[Robert Dewar]

Joe said

<<If the same problems and misunderstandings keep arising, perhaps this is a
good area to write some FAQ items about.
>>

Well of course it is not exactly the same problems and misunderstandings,
each customer's case that we help with tends to be a different situation
(support is not a shrink wrapped replicated item :-)

But I agree that a general FAQ writeup would be useful and it would be nice
if someone would do one!

Re: Size of 0..255 is not 8 bits?

[Joe Gwinn]

In article <dewar.895323945@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> Joe said
> 
> <<If the same problems and misunderstandings keep arising, perhaps this is a
> good area to write some FAQ items about.
> >>
> 
> Well of course it is not exactly the same problems and misunderstandings,
> each customer's case that we help with tends to be a different situation
> (support is not a shrink wrapped replicated item :-)
> 
> But I agree that a general FAQ writeup would be useful and it would be nice
> if someone would do one!

I can't think of anyone in a better position to write such FAQ items than
Robert Dewar, who by virtue of his GNAT related activities at ACT sees
much more of the pattern of usual and customary user errors than most of
us put together.

Joe Gwinn