Re: Rules for Representation of Subtypes

Re: Rules for Representation of Subtypes

[Robert Dewar]

Keith said

"(Publicly disputing Robert Dewar is always dangerous.  Fortunately it's
a bounded error; the effect is limited to learning something.)"

Actually Keith has a pretty good track record in such disputes, he is
seldom wrong :-)

Well in fact I don't see a significant dipute here, I agree with everything
Keith said. The one interesting additional piece of information is that

there is another compiler besides Intermetrics that made Natural'Size 31.
I certainly am aware that Alsys makde Natural'Size be 31, and I am
(painfully, because it causes some compatibility problems for some of
our customers) aware that Verdix made Natural'Size 32. Keith for interest
which compiler made natural'Size 31? It's interesting to know, since it
means that the Ada 95 decision is more justified (i.e. we had a chaotic
non-portable situation in Ada 83, and Ada 95 eliminated the non-portability,
but was bound to cause some incompatibilities for certain implementations
when it did so.

Re: Rules for Representation of Subtypes

[Keith Thompson]

In <dewar.843920326@schonberg> dewar@schonberg.cs.nyu.edu (Robert Dewar) writes:
> The one interesting additional piece of information is that
> there is another compiler besides Intermetrics that made Natural'Size 31.
> I certainly am aware that Alsys makde Natural'Size be 31, and I am
> (painfully, because it causes some compatibility problems for some of
> our customers) aware that Verdix made Natural'Size 32. Keith for interest
> which compiler made natural'Size 31? It's interesting to know, since it
> means that the Ada 95 decision is more justified (i.e. we had a chaotic
> non-portable situation in Ada 83, and Ada 95 eliminated the non-portability,
> but was bound to cause some incompatibilities for certain implementations
> when it did so.

I was referring to TeleSoft's RISCAda compiler.  (Well, it was originally
TeleSoft's.)

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL

Re: Rules for Representation of Subtypes

[W. Wesley Groleau (Wes)]

The opinion was expressed that the generic formals for unchecked_conversion
have to be the same size or at least source smaller than target.  I choose
not to comment on the truth or falsehood of that opinion, but I offer the
behavior of three vendors (Ada-83 except gnat):

Apex on SPARC:  If source is larger than target, the warning message in
the semantic phase is that they are not the same size.  However, you do not
see the warnings unless there are also errors to justify opening the
message window.

Alsys on HP RISC:  NO diagnostic at all if default compiler settings are
used.  In the one case I tested, the code also seemed to work, i.e. the
lost information just happened to not be needed.  Since I did not decide
whether to use the default settings, I haven't bothered to try others.

GNAT: Code rejected when source and target were not the same size.
I've forgotten which was larger.

I haven't used Verdix in 18 months, but if I remember right, it allowed
source to be larger than target WITH a warning.  Similar memory for
VAX Ada, though I haven't used that in five years.  Unfortunately, many
coders suppress warnings because "there are so @$#^$%^*&$ many of them,
they just hide the real problems."

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Hughes Defense Communications (MS 10-40)                 Home: 219-471-7206
Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Rules for Representation of Subtypes

[Robert Dewar]

Wes incorrectly noted:

GNAT: Code rejected when source and target were not the same size.
I've forgotten which was larger.



This is wrong. GNAT accepts unchecked conversions between different
sized types with a warning message.

Re: Rules for Representation of Subtypes

[Ken Garlington]

W. Wesley Groleau (Wes) wrote:
> [snip]
> I haven't used Verdix in 18 months, but if I remember right, it allowed
> source to be larger than target WITH a warning.  Similar memory for
> VAX Ada, though I haven't used that in five years.  Unfortunately, many
> coders suppress warnings because "there are so @$#^$%^*&$ many of them,
> they just hide the real problems."

DEC Ada v3.2 still permits dissimilar sizes. Here's the code I tried:

with Unchecked_Conversion;
package UC_Pkg is

  type S_Type is range 0 .. 16#7FFF_FFFF#;
  for S_Type'Size use 32;

  type T_Type is range 0 .. 10;
  for T_Type'Size use 4;

  function S_to_T is new Unchecked_Conversion (S_Type, T_Type);

  S : S_Type := 16#FFFF#;
  T : T_Type;

end;

with UC_Pkg; use UC_Pkg;
with Text_IO;
procedure UC is
begin
  T := S_to_T(S);  -- examining T in the DEC debugger after this statement
                   -- shows T to be equal to 16#F#.

  Text_IO.Put_Line(T_Type'Image(T));  -- prints "-1" (16#F# as two's complement)
end;

In Ada 83, there's an AI that permits the unchecked conversion to be rejected,
but it's not required.

> 
> ---------------------------------------------------------------------------
> W. Wesley Groleau (Wes)                                Office: 219-429-4923
> Hughes Defense Communications (MS 10-40)                 Home: 219-471-7206
> Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
> ---------------------------------------------------------------------------

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Rules for Representation of Subtypes

[Franco Mazzanti]

Robert A Duff wrote:

> >generic
> >   type Source(<>) is limited private;
> >   type Target is (<>);
> >function Checked_Scalar_Conversion (S:Source) return Target; 
> >
> >
> >with Unchecked_Conversion;
> >function Checked_Scalar_Conversion (S : Source) return Target is
> >   type My_Rec is record
> >      Scalar : Target;
> 
> That's illegal, since Target has unknown discrims.  But other than that,
> this approach will work.
> 
> But, you don't really need to go to all that trouble.  If you just make
> sure your integer types match the hardware (like -2**31..2**31-1 or
> whatever), then unchecked conv of integers will tend to work just fine.
>  ...
>  ...
> 
> - Bob

illegal? isn't Target required to be just a discrete type [RM 12.5.2(2)]?
If I am wrong, is this a GNAT bug (since it compiles without problem)?

Notice that all this trouble might be needed if I want my program to be
as far as possible implementation-independent, or if I want to look for
same mechanically verifiable (as far as possible implementation-independent)
safe coding guidelines (without going to disallow all unchecked conversions).

Franco

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <mazzanti-0310961743320001@131.114.200.115>,
Franco Mazzanti <mazzanti@iei.pi.cnr.it> wrote:
>illegal? isn't Target required to be just a discrete type [RM 12.5.2(2)]?
>If I am wrong, is this a GNAT bug (since it compiles without problem)?

Oh, sorry, my mistake.

- Bob

Re: Rules for Representation of Subtypes

[Franco Mazzanti]

Larry wrote:
> So can someone give an example of how Z'Valid _might_ be useful
> after an unchecked conversion, as seems to be indicated by the
> Reference Manual.

Bob wrote:
> If you unchecked_convert to a record (which is the usual case), then
> you can usefully use 'Valid on the components.  Be sure that the record
> doesn't contain fancy stuff (details in the RM), but a record containing
> scalar fields and constrained arrays will work. 


Then the following should work too ...

generic
   type Source(<>) is limited private;
   type Target is (<>);
function Checked_Scalar_Conversion (S:Source) return Target; 


with Unchecked_Conversion;
function Checked_Scalar_Conversion (S : Source) return Target is
   type My_Rec is record
      Scalar : Target;
   end record;
   Tmp : My_Rec;
   My_Scalar: Target renames Tmp.Scalar;
   -- small trick: even if Tmp as a whole record becomes abnormal
   -- its scalar component can still be safely checked for validity
   -- without "using" the abnormal record object as a prefix.
   function Unchecked_Cvt is new Unchecked_Conversion (Source, My_Rec);
begin
   if My_Rec'Size /= Source'Size or
        My_rec'Alignment /= Source'Alignment then
      raise Program_Error;
   end if;
   Tmp := Unchecked_Cvt (S);
   if My_Scalar'Valid then
      return My_Scalar;
   else
      raise Program_Error;
   end if;
end Checked_Scalar_Conversion; 


At least, when I tried this with gnat it seemed to work.
The following is a simple test program:

with Unchecked_Conversion;
with Checked_Scalar_Conversion;
procedure Main is
   type T is access Integer;
   for T'Size use 32;
   type My_Scalar is new Integer range 1 .. Integer'Last;
   for My_Scalar'Size use 32;
   type My_Scalar2 is new Integer range 1 .. 10;
   for My_Scalar2'Size use 32;
   function Cvt is new Checked_Scalar_Conversion (T, My_Scalar);
   function Cvt is new Checked_Scalar_Conversion (T, My_Scalar2);
   function Cvt is new Unchecked_Conversion (T, Integer);
   Ptr : T := new Integer;
   I : Integer;
   N : My_Scalar;
   S : My_Scalar2;
begin
   I := Cvt (Ptr);                          -- safely converts
   Text_Io.Put_Line (Integer'Image(I));
   N := Cvt (Ptr);                          -- safely converts
   Text_Io.Put_Line (My_Scalar'Image(N));
   S := Cvt (Ptr);                          -- raises Program_Error
   Text_Io.Put_Line (My_Scalar2'Image(S));
end Main; 

Actually, at a rigorous reading, the behavior has just changed from
"erroneous" [RM 13.9.1(12)]" to "implementation-defined" [RM 13.9 (10,
11)]. And "implementation-defined" may still include the possibility of
"erroneousness". But hopefully this not likely not to be the common case.

Franco 

----------------
Franco Mazzanti    <mazzanti@iei.pi.cnr.it>

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <mazzanti-0210961730430001@131.114.200.115>,
Franco Mazzanti <mazzanti@iei.pi.cnr.it> wrote:
>Then the following should work too ...

Well, almost...

>generic
>   type Source(<>) is limited private;
>   type Target is (<>);
>function Checked_Scalar_Conversion (S:Source) return Target; 
>
>
>with Unchecked_Conversion;
>function Checked_Scalar_Conversion (S : Source) return Target is
>   type My_Rec is record
>      Scalar : Target;

That's illegal, since Target has unknown discrims.  But other than that,
this approach will work.

But, you don't really need to go to all that trouble.  If you just make
sure your integer types match the hardware (like -2**31..2**31-1 or
whatever), then unchecked conv of integers will tend to work just fine.

>At least, when I tried this with gnat it seemed to work.

Careful.  Erroneous means anything might happen, and "it works fine" is
one possible outcome.  But just because if works fine on GNAT doesn't
mean it will work fine on other compilers, or other versions of GNAT
(assuming it really is erroneous).

- Bob

Re: Rules for Representation of Subtypes

[Robert Dewar]

Bob Duff said

">BTW: Why doesn't Ada have a 'Storage_Size clause for (non-access) types or
>objects?

It should."


I am completely puzzled, you can specify the size of types and the size of
objects, what on earth woul it mean to specify Storage_Size for an array
(as opposed to specifying the type or object size for the array).

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <dewar.843920464@schonberg>,
Robert Dewar <dewar@schonberg.cs.nyu.edu> wrote:
I wrote:
>It should."
And Robert replied:
>I am completely puzzled, you can specify the size of types and the size of
>objects, what on earth woul it mean to specify Storage_Size for an array
>(as opposed to specifying the type or object size for the array).

The complaint was that Ada measures everythng in bits, and why can't you
specify sizes in bytes, or storage units, or whatever, which is much
more convenient in many cases.  That's what I was saying "It should" to.

- Bob

Re: Rules for Representation of Subtypes

[Matthew Heaney]

In article <DyGy7y.Hy5@world.std.com>, bobduff@world.std.com (Robert A
Duff) wrote:

>In article <dewar.843920464@schonberg>,
>Robert Dewar <dewar@schonberg.cs.nyu.edu> wrote:
>I wrote:
>>It should."
>And Robert replied:
>>I am completely puzzled, you can specify the size of types and the size of
>>objects, what on earth woul it mean to specify Storage_Size for an array
>>(as opposed to specifying the type or object size for the array).
>
>The complaint was that Ada measures everythng in bits, and why can't you
>specify sizes in bytes, or storage units, or whatever, which is much
>more convenient in many cases.  That's what I was saying "It should" to.

And I agree, too!

   O'Storage_Units

makes a lot more sense than

   O'Size / System.Storage_Unit

Why not just save me the trouble, and make 'Storage_Units a predefined
language attribute?

I'd actually go further and make

   O'Bytes 

a predefined language attribute, which the compiler is free to reject if
Storage_Unit /= 8 on this machine.

I'm always a little nervous when I'm making an OS call that explicitly
calls for length in bytes, yet I have to express the length in terms of
Storage_Units.  I know that thinking in terms Storage_Units is more
portable, but there's nothing portable about 

   Starlet.QIO (
      ...
      P1 => O'Address,
      P2 => O'Size / System.Storage_Unit,
      ...

QIO  wants bytes, so why not let me say that directly?

>- Bob

matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Rules for Representation of Subtypes

[Robert Dewar]

Bob Duff said

"In article <dewar.843920464@schonberg>,
Robert Dewar <dewar@schonberg.cs.nyu.edu> wrote:
I wrote:
>It should."
And Robert replied:
>I am completely puzzled, you can specify the size of types and the size of
>objects, what on earth woul it mean to specify Storage_Size for an array
>(as opposed to specifying the type or object size for the array).

The complaint was that Ada measures everythng in bits, and why can't you
specify sizes in bytes, or storage units, or whatever, which is much
more convenient in many cases.  That's what I was saying "It should" to.

- Bob"


Ah, OK, fine, but the use of Storage_Size is most misleading, since this
does not refer to the space in storage units taken up by a value of the
type!

I absolutely agree that this is a missing capability, and if you look back
at one of my previous messages, you will see that I suggested the
attribute "Size_In_Storage_Units for this purpose. (note that
Max_Size_In_Storage_Units is not right, because it can include
templates, bounds etc, but for many types they will be the same).
\x1adp

Re: Rules for Representation of Subtypes

[Art Schwarz]

Nearest that I can remember, byte size varies by machine. It is NOT an
eight byte quantity. This is probably the motivation to use _octet_
instead of bytes in formal descriptions.

  An example of byte sizes:  CDC 1604    6 bits
                             CDC 6000   12 bits
                             PC          8 bits
                             UNIVAC 1100 7, 8, 9, 12 bits
                             PDP-10      7 bits (and others?)

art schwarz

(No opinion is held more dearly than the one's I must let go.)


In article <dewar.844014110@schonberg>, dewar@schonberg.cs.nyu.edu (Robert Dewar) writes:
>Bob Duff said
>
>"In article <dewar.843920464@schonberg>,
>Robert Dewar <dewar@schonberg.cs.nyu.edu> wrote:
>I wrote:
>>It should."
>And Robert replied:
>>I am completely puzzled, you can specify the size of types and the size of
>>objects, what on earth woul it mean to specify Storage_Size for an array
>>(as opposed to specifying the type or object size for the array).
>
>The complaint was that Ada measures everythng in bits, and why can't you
>specify sizes in bytes, or storage units, or whatever, which is much
>more convenient in many cases.  That's what I was saying "It should" to.
>
>- Bob"
>
>
>Ah, OK, fine, but the use of Storage_Size is most misleading, since this
>does not refer to the space in storage units taken up by a value of the
>type!
>
>I absolutely agree that this is a missing capability, and if you look back
>at one of my previous messages, you will see that I suggested the
>attribute "Size_In_Storage_Units for this purpose. (note that
>Max_Size_In_Storage_Units is not right, because it can include
>templates, bounds etc, but for many types they will be the same).
>\x1adp
>

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <52oi3v$din@mill.gdls.com>, Art Schwarz <schwarza@gdls.com> wrote:
>                             PDP-10      7 bits (and others?)

On the PDP-10, a byte could be any size from 1 to 36 bits (or 0 to 35,
or something like that).  But a storage unit was 36 bits.  Some people,
these days, mean "addressable storage unit" when they say "byte", but it
used to mean "a part of a word" (maybe addressable or maybe not).  And
of course it's come to mean "8 bits" to many.  Probably most programmers
in their twenties think that God made the byte 8 bits wide.  ;-)

- Bob

Re: Rules for Representation of Subtypes

[Larry Kilgallen]

In article <52oi3v$din@mill.gdls.com>, schwarza@gdls.com (Art Schwarz) writes:
> Nearest that I can remember, byte size varies by machine. It is NOT an
> eight byte quantity. This is probably the motivation to use _octet_
> instead of bytes in formal descriptions.
> 
>   An example of byte sizes:  CDC 1604    6 bits
>                              CDC 6000   12 bits
>                              PC          8 bits
>                              UNIVAC 1100 7, 8, 9, 12 bits
>                              PDP-10      7 bits (and others?)

The PDP-10 could handle any byte size from 1 to 35 (36 also worked
in hardware, but was a degenerate case, since it was the fullword).

Sizes which were popular in software included 6 and 7, providing
6 and 5 bytes per fullword.  In the case of 7 bit bytes, there
was one bit left over per fullword, and there were cases where
that bit was used for some purpose.

Now I am not predicting that the PDP-10 instruction set will make
a big comeback, but having seen the PDP-10 and the Alpha, I am
certainly not going to claim the ability to predict the nature
of computer hardware thirty years hence.

Several programming languages have survived 30 years, so whatever
that future hardware looks like, Ada programmers should be ready
for it.

Will the demand for Unicode support make 16 bits the typical
size of a Storage Unit ?  Or will egalitarian support for
those Korean dialects drive it to 32 bits ?

Larry Kilgallen

Re: Rules for Representation of Subtypes

[Brian R. Hanson]

In article <52oi3v$din@mill.gdls.com>, schwarza@gdls.com (Art Schwarz)
writes:
> Nearest that I can remember, byte size varies by machine. It is NOT an
> eight byte quantity. This is probably the motivation to use _octet_
> instead of bytes in formal descriptions.
>
>   An example of byte sizes:  CDC 1604    6 bits
>                              CDC 6000   12 bits
>                              PC          8 bits
>                              UNIVAC 1100 7, 8, 9, 12 bits
>                              PDP-10      7 bits (and others?)

On the CDC 6xxx line a "byte" was probably 6 bits - the size needed
to typically represent a character.  12 bits was the size of a parcel
which was the minimum size for an instruction.  12 bits was also the 
size of a word of memory in the associated peripheral units used to 
do io to and from memory. The smallest addressable unit of storage 
for the main processor was 60 bits - the size of a word.  

-- Brian Hanson
-- brh@cray.com

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <1996Oct1.125614.1@eisner>,
Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>Will the demand for Unicode support make 16 bits the typical
>size of a Storage Unit ?  Or will egalitarian support for
>those Korean dialects drive it to 32 bits ?

No.  To efficiently handle unicode, you need to do some sort of packing.
Even with cheap memory, space optimization matters, because space
optimization implies speed optimization when using caches and paging to
disks.

I suspect 8-bit bytes will be around for a long time, since there's a
lot of C code that depends on it.  I also suspect that word sizes will
be powers of 2 for a long time.  Except for the minor factor of existing
software, today's 64-bit machines would be either 64-bit-addressable, or
1-bit-addressable, methinks.

- Bob

Re: Rules for Representation of Subtypes

[Robert Dewar]

Bob Duff said

"But this is all very obscure.  If you're interfacing to hardware, or to
C, or to something else where the interface is a low-level binary
interface, the best thing to do is make the types match the hardware, or
the C, or whatever it is.  Don't use constraints on the Ada side of the
interface, just because the logical properties would warrant a
constraint.
"

If you are using GNAT, you need not worry about this. We found that so
many users were depending on objects of a subtype being the same as
objects of the base type that it was essential to do this. If you use
a compiler that does NOT have this convention with existing Ada 83
code, our experience is that you will likely run into troubles.

At the very least, I think that a compiler should regard a subtype
object as having  the same size as the base type for convention C.

i.e. the implementatiojn advice in the RM to squeeze things down is
actively undesirable for pragma foreign conventions where this would
not be done by the foriegn language.

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <dewar.843920516@schonberg>,
Robert Dewar <dewar@schonberg.cs.nyu.edu> wrote:
>If you are using GNAT, you need not worry about this. ...

Well, *some* people might desire to write standard Ada, as opposed to
the GNAT dialect.  ;-)

Anyway, are you saying that GNAT fails to optimize cases like this:

    X: Integer range 1..10 := 1;
    ...
    if X < 10 then -- must be true

But what if the "..." contains an unchecked conversion that sets X to
11?

- Bob

Re: Rules for Representation of Subtypes

[Matthew Heaney]

In article <DyGyFv.JA1@world.std.com>, bobduff@world.std.com (Robert A
Duff) wrote:

>Anyway, are you saying that GNAT fails to optimize cases like this:
>
>    X: Integer range 1..10 := 1;
>    ...
>    if X < 10 then -- must be true
>
>But what if the "..." contains an unchecked conversion that sets X to
>11?

That's easy: program execution is erroneous.  Very likely the compiler
*will* make that optimization. s

If one leaves the language (via unchecked_conversion) and violates the type
constraints, then he the programmer is at fault.  Who can say what the
compiler does, because program behaviour is in fact undefined.

>- Bob

Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Rules for Representation of Subtypes

[Matthew Heaney]

I've always been curious about the rules for representation of subtypes. 
For example, if I make a declaration like this:

   A_Small_Integer : Integer range 0 .. 255;  -- assume type Integer is 4 bytes

then is an implementation allowed to use fewer than 4 bytes to represent
A_Small_Integer?

Suppose I'm on a Unix system and I do this

   read (fd, A_Small_Integer'Address, 4);

If the representation of A_Small_Integer is only 1 byte, then obviously I'm
in trouble.  Am I required to specify the size of objects?

   A_Small_Integer : Integer range 0 .. 255;
   for A_Small_Integer'Size use 32;                     -- required?

matt
mheaney@ni.net

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <mheaney-ya023080002209961353500001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>I've always been curious about the rules for representation of subtypes. 
>For example, if I make a declaration like this:
>
>   A_Small_Integer : Integer range 0 .. 255;  -- assume type Integer is 4 bytes
>
>then is an implementation allowed to use fewer than 4 bytes to represent
>A_Small_Integer?

Yes.

>Suppose I'm on a Unix system and I do this
>
>   read (fd, A_Small_Integer'Address, 4);
>
>If the representation of A_Small_Integer is only 1 byte, then obviously I'm
>in trouble.  Am I required to specify the size of objects?

Well, you could.  But a better solution is to always say "aliased" when
you have a variable you want to take 'Address of.  Aliased variables
will generally be represented the same way, for all variables of the
type.

Also, the number 4 is questionable.  What are you trying to do?  Read 4
bytes of data?  Well in that case, you want to make sure the target
variable is 4 bytes (which your code doesn't do).  Or are you trying to
read however-many-bytes it takes to fill up A_Small_Integer?  In that
case, you should be asking for that number of bytes, not 4 bytes.  (You
can calculate it based on 'Size, which, unfortunately, is in bits.)

>   A_Small_Integer : Integer range 0 .. 255;
>   for A_Small_Integer'Size use 32;                     -- required?

That will make it the right size.  But if you read 4 non-zero bytes,
your program will be erroneous.

- Bob

Re: Rules for Representation of Subtypes

[Matthew Heaney]

In article <Dy78qJ.MDr@world.std.com>, bobduff@world.std.com (Robert A
Duff) wrote:

>>I've always been curious about the rules for representation of subtypes. 
>>For example, if I make a declaration like this:
>>
>>   A_Small_Integer : Integer range 0 .. 255;  -- assume type Integer is 4
bytes
>>
>>then is an implementation allowed to use fewer than 4 bytes to represent
>>A_Small_Integer?
>
>Yes.
>
>>Suppose I'm on a Unix system and I do this
>>
>>   read (fd, A_Small_Integer'Address, 4);
>>
>>If the representation of A_Small_Integer is only 1 byte, then obviously I'm
>>in trouble.  Am I required to specify the size of objects?
>
>Well, you could.  But a better solution is to always say "aliased" when
>you have a variable you want to take 'Address of.  Aliased variables
>will generally be represented the same way, for all variables of the
>type.

You say "generally" be represented the same way: can you be more specific? 
Under what circumstances can they be different?

>Also, the number 4 is questionable.  What are you trying to do?  Read 4
>bytes of data?  Well in that case, you want to make sure the target
>variable is 4 bytes (which your code doesn't do).  Or are you trying to
>read however-many-bytes it takes to fill up A_Small_Integer?  In that
>case, you should be asking for that number of bytes, not 4 bytes.  (You
>can calculate it based on 'Size, which, unfortunately, is in bits.)

Perhaps this was a poor example: I would never actually do it that way in
real code.  I just needed an example to ask my question about size of
objects of subtypes. 

Better is:

   A_Small_Integer: Interfaces.Integer_32 range 0 .. 255;

But of course, if I'm going to read 4 bytes from an OS call, then

   The_Value : Interfaces.Integer_32;

is best.


BTW: Why doesn't Ada have a 'Storage_Size clause for (non-access) types or
objects?  If everywhere I want storage units, I have to do this:

   read (fd, O'Address, O'Size / System.Storage_Unit);

If "number of storage units" is required so much, and the expression
O'Size/System.Storage_Unit is so popular, then why didn't the Ada designers
save me the trouble, so I could say

   read (fd, O'Address, O'Storage_Units);

or even

   read (fd, O'Address, O'Number_Of_Bytes);

I've seen this kind of error often, where the programmer sends the 'Size
without dividing by 8 first.  The error is exacerbated when documentation
(say, on a Unix box) refers to size, and means "number of bytes."  So easy
to forget to divide O'Size by 8!

Byte-size is an undeniably popular unit of measure in programming.  The
fact that there's no *direct* support for it in Ada seems to me to be an
egregious oversight.  (But I'm sure there was a reason...)


Here's another question:

   type T is new Interfaces.Integer_32 range 0 .. 255;

What is the size of T?  Do I need to specify a size clause to ensure that
objects of type T are 4 bytes?

>>   A_Small_Integer : Integer range 0 .. 255;
>>   for A_Small_Integer'Size use 32;                     -- required?
>
>That will make it the right size.  But if you read 4 non-zero bytes,
>your program will be erroneous.

You are of course correct.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <mheaney-ya023080002409960726040001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>You say "generally" be represented the same way: can you be more specific? 
>Under what circumstances can they be different?

Well, aliased Strings could be different sizes, for example.

>BTW: Why doesn't Ada have a 'Storage_Size clause for (non-access) types or
>objects?

It should.

>Here's another question:
>
>   type T is new Interfaces.Integer_32 range 0 .. 255;
>
>What is the size of T?  Do I need to specify a size clause to ensure that
>objects of type T are 4 bytes?

Yes.

But this is all very obscure.  If you're interfacing to hardware, or to
C, or to something else where the interface is a low-level binary
interface, the best thing to do is make the types match the hardware, or
the C, or whatever it is.  Don't use constraints on the Ada side of the
interface, just because the logical properties would warrant a
constraint.

For example, suppose you call a C function that takes a pointer to an
int, and the function updates the pointed-to int.  The documentation
promises that the value will always be in 1..10.  DO NOT say "type T is
range 1..10;", or "subtype T is Interfaces.C.int range 1..10;" on the
Ada side.  Because, if the documentation lies, your program will be
erroneous.  If, on the other hand, you use Interfaces.C.int, at the
interface, and *then* assign it into a constrained thing, you will get a
Constraint_Error for the bad data.  Or, you can write an "if" statement
to check for bad data.

- Bob

Re: Rules for Representation of Subtypes

[Larry Kilgallen]

In article <DyCF97.7zp@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:

> But this is all very obscure.  If you're interfacing to hardware, or to
> C, or to something else where the interface is a low-level binary
> interface, the best thing to do is make the types match the hardware, or
> the C, or whatever it is.  Don't use constraints on the Ada side of the
> interface, just because the logical properties would warrant a
> constraint.
> 
> For example, suppose you call a C function that takes a pointer to an
> int, and the function updates the pointed-to int.  The documentation
> promises that the value will always be in 1..10.  DO NOT say "type T is
> range 1..10;", or "subtype T is Interfaces.C.int range 1..10;" on the
> Ada side.  Because, if the documentation lies, your program will be
> erroneous.  If, on the other hand, you use Interfaces.C.int, at the
> interface, and *then* assign it into a constrained thing, you will get a
> Constraint_Error for the bad data.  Or, you can write an "if" statement
> to check for bad data.

Like:

	if X'Valid

?  I would think that as being an argument in _favor_ of declaring
the C-updated object in a tightly constrained fashion.

Larry Kilgallen

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <1996Sep26.191257.1@eisner>,
Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>Like:
>
>	if X'Valid
>
>?  I would think that as being an argument in _favor_ of declaring
>the C-updated object in a tightly constrained fashion.

No, that won't work.  By the time you get to that if statement, the
program execution is already erroneous.  Compilers can and do (and
should) take advantage of that fact to generate faster code that doesn't
work.  An unchecked conversion is a function call, and there's no way to
capture the result of it without assigning it somewhere, which causes
erroneousness if the result is bad.

- Bob

Re: Rules for Representation of Subtypes

[Mark A Biggar]

In article <DyEr6p.38H@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
>In article <1996Sep26.191257.1@eisner>,
>Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>>Like:
>>	if X'Valid
>>?  I would think that as being an argument in _favor_ of declaring
>>the C-updated object in a tightly constrained fashion.
>No, that won't work.  By the time you get to that if statement, the
>program execution is already erroneous.  Compilers can and do (and
>should) take advantage of that fact to generate faster code that doesn't
>work.  An unchecked conversion is a function call, and there's no way to
>capture the result of it without assigning it somewhere, which causes
>erroneousness if the result is bad.

I'm not sure about this as I always thought that the RM was pretty clear
that only the USE of an abnormal value was erroneous, but that simply
assigning it was safe, at least I'm sure that was the intent, otherwise
X'VALID after an unchecked conversion is useless, but that is one of the
explisit examples of its intended use in the RM.

--
Mark Biggar
mab@wdl.lmco.com

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <52hnvh$li0@wdl1.wdl.lmco.com>,
Mark A Biggar <mab@dst17.wdl.loral.com> wrote:
>I'm not sure about this as I always thought that the RM was pretty clear
>that only the USE of an abnormal value was erroneous, but that simply
>assigning it was safe, at least I'm sure that was the intent, otherwise
>X'VALID after an unchecked conversion is useless, but that is one of the
>explisit examples of its intended use in the RM.

Well, assignment is a USE -- you can't assign from an abnormal object
without going erroneous.  But that's beside the point -- the case I was
talking about is defined as erroneous, not as abnormal.

13.9.1(12) says:

12   {erroneous execution} A call to an imported function or an instance of
Unchecked_Conversion is erroneous if the result is scalar, and the result
object has an invalid representation.

The AARM gives an example:

        12.c   Consider the following example:

12.d        type My_Int is range 0..99;
            function Safe_Convert is new Unchecked_Conversion(My_Int, Integer);
            function Unsafe_Convert is new Unchecked_Conversion(My_Int, Positiv\
e);
            X : Positive := Safe_Convert(0); -- Raises Constraint_Error.
            Y : Positive := Unsafe_Convert(0); -- Erroneous.

        12.e   The call to Unsafe_Convert causes erroneous execution.  The
        call to Safe_Convert is not erroneous.  The result object is an
        object of subtype Integer containing the value 0.  The assignment to
        X is required to do a constraint check; the fact that the conversion
        is unchecked does not obviate the need for subsequent checks required
        by the language rules.

The point is that you should convert to a type that "fills all the
bits".  That is, there are no possible bit patterns that don't represent
valid data.  Then, *after* the unchecked conversion, you can do an
assignment that does a constraint check.  Checking Y'Valid in the above
example would not help, since the program is already erroneous.  The
'Valid feature is just like anything else -- it won't work as advertised
if the execution is already erroneous.

Or you can use an if statement:

    Z: Integer := Safe_Convert(0);
    ...
    if Z not in My_Int then
        raise Horrible_Bug;

The same applies to imported functions.  So, for example, if you have a
C function that returns 'int', and the documentation says this 'int'
will be in the range 1..10, it's best to use Interfaces.C.int as the
result subtype, and do some checking *after* it returns.  This is
because Interfaces.C.int matches the type 'int' in C.  Unless you
really, really trust that documentation.

- Bob

Re: Rules for Representation of Subtypes

[Larry Kilgallen]

In article <DyKC85.Gqx@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:

> The point is that you should convert to a type that "fills all the
> bits".  That is, there are no possible bit patterns that don't represent
> valid data.  Then, *after* the unchecked conversion, you can do an
> assignment that does a constraint check.  Checking Y'Valid in the above
> example would not help, since the program is already erroneous.  The
> 'Valid feature is just like anything else -- it won't work as advertised
> if the execution is already erroneous.

So can someone give an example of how Z'Valid _might_ be useful
after an unchecked conversion, as seems to be indicated by the
Reference Manual.

Larry Kilgallen

Re: Rules for Representation of Subtypes

[Samuel Tardieu]

>>>>> "Larry" == Larry Kilgallen <kilgallen@eisner.decus.org> writes:

Larry> So can someone give an example of how Z'Valid _might_ be useful
Larry> after an unchecked conversion, as seems to be indicated by the
Larry> Reference Manual.

I don't think that the Valid attribute has been put in the language to
be used after an Unchecked_Conversion, but rather to be used after
calls to imported subprograms and calls to Read attributes (data
coming from a stream).

  Sam
-- 
  Samuel Tardieu -- sam@ada.eu.org

Re: Rules for Representation of Subtypes

[Ken Garlington]

Samuel Tardieu wrote:
> 
> >>>>> "Larry" == Larry Kilgallen <kilgallen@eisner.decus.org> writes:
> 
> Larry> So can someone give an example of how Z'Valid _might_ be useful
> Larry> after an unchecked conversion, as seems to be indicated by the
> Larry> Reference Manual.
> 
> I don't think that the Valid attribute has been put in the language to
> be used after an Unchecked_Conversion, but rather to be used after
> calls to imported subprograms and calls to Read attributes (data
> coming from a stream).

I don't know much, but I do know this: I specifically wrote a revision
request to Ada 83 to handle the following situation:

  type Foo is range 1 .. 10;
  X: Foo; -- assume that this takes up a storage unit with a range
          -- greater than 1 .. 10
  ...

  Read(X); -- some I/O operation, unchecked conversion, whatever
           -- that might put a bit pattern in X that is not in 1 .. 10

  if X in Foo then
    raise Some_Exception; -- rarely works in Ada 83 due to optimization
  end if;

I thought one of the important uses of X'Valid was to be able to test 
for a legal bit pattern, and never mind the optimizations. If it doesn't 
work, then why did I go to all the trouble to write the RR?

-- 
LMTAS - "Our Brand Means Quality"

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <1996Oct1.100608.1@eisner>,
>So can someone give an example of how Z'Valid _might_ be useful
>after an unchecked conversion, as seems to be indicated by the
>Reference Manual.

If you unchecked_convert to a record (which is the usual case), then you
can usefully use 'Valid on the components.  Be sure that the record
doesn't contain fancy stuff (details in the RM), but a record containing
scalar fields and constrained arrays will work.

- Bob

Re: Rules for Representation of Subtypes

[Larry Kilgallen]

In article <DyEr6p.38H@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:
> In article <1996Sep26.191257.1@eisner>,
> Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>>Like:
>>
>>	if X'Valid
>>
>>?  I would think that as being an argument in _favor_ of declaring
>>the C-updated object in a tightly constrained fashion.
> 
> No, that won't work.  By the time you get to that if statement, the
> program execution is already erroneous.  Compilers can and do (and
> should) take advantage of that fact to generate faster code that doesn't
> work.  An unchecked conversion is a function call, and there's no way to
> capture the result of it without assigning it somewhere, which causes
> erroneousness if the result is bad.

If the assignment of the output causes erroneousness,
then why isn't the name of the operation Checked Conversion ?

Larry Kilgallen

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <1996Sep28.155354.1@eisner>,
Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>If the assignment of the output causes erroneousness,
>then why isn't the name of the operation Checked Conversion ?

Heh?  If it were checked, it would do something sensible, like raise an
exception, or return a well-defined result, or give a compile-time
error.  The UNchecked means, it's *not* checked -- if you do something
wrong, you get unpredictable behavior, i.e. erroneous execution.

- Bob

Re: Rules for Representation of Subtypes

[Matthew Heaney]

In article <DyGwtp.Bs1@world.std.com>, bobduff@world.std.com (Robert A
Duff) wrote:

>In article <1996Sep28.155354.1@eisner>,
>Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>>If the assignment of the output causes erroneousness,
>>then why isn't the name of the operation Checked Conversion ?
>
>Heh?  If it were checked, it would do something sensible, like raise an
>exception, or return a well-defined result, or give a compile-time
>error.  The UNchecked means, it's *not* checked -- if you do something
>wrong, you get unpredictable behavior, i.e. erroneous execution.

I think his comment was in reaction a previous post, which stated that the
compiler would make all kinds of optimizations based on what it knew was an
illegal program as a result of a call to unchecked_conversion.  If the
compiler does something "special" to handle a "bad" program because of
unchecked_conversion, well, the conversion is not really "unchecked,"
right?

>- Bob

Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <mheaney-ya023180002909961030520001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>I think his comment was in reaction a previous post, which stated that the
>compiler would make all kinds of optimizations based on what it knew was an
>illegal program as a result of a call to unchecked_conversion.  If the
 ^^^^^^^ You mean "erroneous".
>compiler does something "special" to handle a "bad" program because of
>unchecked_conversion, well, the conversion is not really "unchecked,"
>right?

No, no, the compiler doesn't *know* the program is bad.  It just does an
optimization that will work if the program is good, and might not work
if the program is bad.

If the compiler *knows* the program is bad, then it should of course
give a warning message.  But usually such things aren't knowable.

- Bob

Re: Rules for Representation of Subtypes

[Robert Dewar]

Matthew said

"I think his comment was in reaction a previous post, which stated that the
compiler would make all kinds of optimizations based on what it knew was an
illegal program as a result of a call to unchecked_conversion.  If the
compiler does something "special" to handle a "bad" program because of
unchecked_conversion, well, the conversion is not really "unchecked,"
right?"

Can you be clearer as to what you mean? For a start I assume that the
use of the word illegal should be erroneous? right?
unchecked simply means that the compiler is not required to generate
checking code for some error conditions, what else do you read into the
word?

Re: Rules for Representation of Subtypes

[Matthew Heaney]

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

>"I think his comment was in reaction a previous post, which stated that the
>compiler would make all kinds of optimizations based on what it knew was an
>illegal program as a result of a call to unchecked_conversion.  If the
>compiler does something "special" to handle a "bad" program because of
>unchecked_conversion, well, the conversion is not really "unchecked,"
>right?"
>
>Can you be clearer as to what you mean? For a start I assume that the
>use of the word illegal should be erroneous? right?
>unchecked simply means that the compiler is not required to generate
>checking code for some error conditions, what else do you read into the
>word?

You're right; I should have said "...knew would cause erroneous program
execution..."  Honestly, though, I'm a little shaky about the difference
between "erroneous execution," "bounded errors," "non portability," and
"illegal program."  Guess I better hit the books before TRI-Ada!

I intended "unchecked" to mean as you suggested: don't put in checks for
error conditions (on the object that is returned by the call to
Unchecked_Conversion).

The author of the post (I think it was Larry K) just wanted to make sure
that the expression containing the Valid attribute didn't get optimized
away.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Rules for Representation of Subtypes

[Larry Kilgallen]

In article <DyGwtp.Bs1@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:
> In article <1996Sep28.155354.1@eisner>,
> Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>>If the assignment of the output causes erroneousness,
>>then why isn't the name of the operation Checked Conversion ?
> 
> Heh?  If it were checked, it would do something sensible, like raise an
> exception, or return a well-defined result, or give a compile-time
> error.  The UNchecked means, it's *not* checked -- if you do something
> wrong, you get unpredictable behavior, i.e. erroneous execution.

But my X'valid should still work.  And compilers are not allowed to
change the flow of a program.

	X := my_unchecked_conversion(Y);

	if X'valid
	then
		Z(247) := X;
	else
		raise my_exception;
	end if;

No optimizer should stash my X into Z until it determines the
result of my conditional.  Likewise for:

	X:= my_unchecked_conversion(Y);

	if not X'valid then raise my_exception; end if;

	Z(247) := X;

no optimizer should stash my X into Z until it knows the result
of the possible flow control change represented by raise my_exception.

Larry Kilgallen

Re: Rules for Representation of Subtypes

[Matthew Heaney]

In article <1996Sep29.082143.1@eisner>, kilgallen@eisner.decus.org (Larry
Kilgallen) wrote:

>But my X'valid should still work.  And compilers are not allowed to
>change the flow of a program.
>
>        X := my_unchecked_conversion(Y);
>
>        if X'valid
>        then
>                Z(247) := X;
>        else
>                raise my_exception;
>        end if;
>
>No optimizer should stash my X into Z until it determines the
>result of my conditional.  Likewise for:
>
>        X:= my_unchecked_conversion(Y);
>
>        if not X'valid then raise my_exception; end if;
>
>        Z(247) := X;
>
>no optimizer should stash my X into Z until it knows the result
>of the possible flow control change represented by raise my_exception.

You raise a good point: no optimizer "should" stash X into Z until the
expression is evalutated.  But what is the rule for optimization of
expressions involving the Valid attribute?  The AARM95, Section 13.9.2
discusses the use of that attribute, but doesn't have anything to say about
whether it is allowed to be optimized away.

My hunch is that a compiler will not optimize away the use of the Valid
attribute to check the results of Unchecked_Conversion, because that is one
the cases explicity called out in the RM95 for its use.

>Larry Kilgallen

Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <1996Sep29.082143.1@eisner>,
Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>But my X'valid should still work.  And compilers are not allowed to
>change the flow of a program.
>
>	X := my_unchecked_conversion(Y);
>
>	if X'valid

It depends on how you instantiated my_unchecked_conversion.  If you used
a constrained integer, such that some values of Y will produce
out-of-range results, then it's erroneous, and the 'Valid will *not*
work.  Hence, my advice to always unchecked_convert to types that match
the hardware.

- Bob

Re: Rules for Representation of Subtypes

[Ken Garlington]

Robert A Duff wrote:
> 
> In article <1996Sep29.082143.1@eisner>,
> Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
> >But my X'valid should still work.  And compilers are not allowed to
> >change the flow of a program.
> >
> >       X := my_unchecked_conversion(Y);
> >
> >       if X'valid
> 
> It depends on how you instantiated my_unchecked_conversion.  If you used
> a constrained integer, such that some values of Y will produce
> out-of-range results, then it's erroneous, and the 'Valid will *not*
> work.  Hence, my advice to always unchecked_convert to types that match
> the hardware.

I seem to remember some AI about using unchecked_conversion when the sizes of X and 
Y are different. Maybe it's compiler dependent, but I thought you were at least 
guaranteed that the unchecked_conversion of Y would _fit_ into the space allocated 
for X, although of course Y might be outside the range of X. In that case, X'Valid 
should work, shouldn't it?

> 
> - Bob

-- 
LMTAS - "Our Brand Means Quality"

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <325155A5.2E50@lmtas.lmco.com>,
Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
>I seem to remember some AI about using unchecked_conversion when the
>sizes of X and Y are different. Maybe it's compiler dependent, but I
>thought you were at least guaranteed that the unchecked_conversion of Y
>would _fit_ into the space allocated for X, although of course Y might
>be outside the range of X. In that case, X'Valid should work, shouldn't
>it?

No.  See 13.9.1(12).  Nothing, not even 'Valid, can be assumed to work,
if the execution is erroneous.

- Bob

Re: Rules for Representation of Subtypes

[Ken Garlington]

Robert A Duff wrote:
> 
> In article <325155A5.2E50@lmtas.lmco.com>,
> Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
> >I seem to remember some AI about using unchecked_conversion when the
> >sizes of X and Y are different. Maybe it's compiler dependent, but I
> >thought you were at least guaranteed that the unchecked_conversion of Y
> >would _fit_ into the space allocated for X, although of course Y might
> >be outside the range of X. In that case, X'Valid should work, shouldn't
> >it?
> 
> No.  See 13.9.1(12).  Nothing, not even 'Valid, can be assumed to work,
> if the execution is erroneous.
> 
> - Bob

So all that discussion in the Ada 83 AI-00590 is wasted when we get to Ada 95?
What a crock!

I'd also say that 13.9.2:1 and 13.9.2:4-12 are very misleading, at best, if
this is the case. It sounds like I would have to write a kludge, wrapping
my scalar inside a record, as the result of my input routine, unchecked conversion,
etc. I hope GNAT and the other compilers raise a warning if I apply 'Valid to
something that is not a record component!

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Rules for Representation of Subtypes

[Robert Dewar]

Bob Duff said

"It depends on how you instantiated my_unchecked_conversion.  If you used
a constrained integer, such that some values of Y will produce
out-of-range results, then it's erroneous, and the 'Valid will *not*
work.  Hence, my advice to always unchecked_convert to types that match
the hardware."

I don't see this, please give an exact example of what you are talking
about, and then exactly justify your statement above from the Ada 95 RM.

Re: Rules for Representation of Subtypes

[Robert Dewar]

Larry said

"If the assignment of the output causes erroneousness,
then why isn't the name of the operation Checked Conversion ?

Larry Kilgallen"


There is some serious misconception in the above question, serious enough
so it is hard to figure out what Larry is getting at. In any case, the
fact that something might be erroneus has nothing to do with implying
the presence of checks -- in fact the exact opposite is true.

Re: Rules for Representation of Subtypes

[Matthew Heaney]

In article <DyCF97.7zp@world.std.com>, bobduff@world.std.com (Robert A
Duff) wrote:

>But this is all very obscure.  If you're interfacing to hardware, or to
>C, or to something else where the interface is a low-level binary
>interface, the best thing to do is make the types match the hardware, or
>the C, or whatever it is.  Don't use constraints on the Ada side of the
>interface, just because the logical properties would warrant a
>constraint.
>
>For example, suppose you call a C function that takes a pointer to an
>int, and the function updates the pointed-to int.  The documentation
>promises that the value will always be in 1..10.  DO NOT say "type T is
>range 1..10;", or "subtype T is Interfaces.C.int range 1..10;" on the
>Ada side.  Because, if the documentation lies, your program will be
>erroneous.  If, on the other hand, you use Interfaces.C.int, at the
>interface, and *then* assign it into a constrained thing, you will get a
>Constraint_Error for the bad data.  Or, you can write an "if" statement
>to check for bad data.

I agree.  As a matter of fact, this is what I do already, and what I tell
all my clients to do.  Most aren't savvy enough about Ada to realize that
their program (execution) is erroneous if the data they just read off the
interface doesn't match the constraints of their Ada type, and most people
expect (incorrectly) that Ada will just raise Constraint_Error if the data
is out of range.

So the moral of the story is, if you're reading data off an interface, read
it into a an object of a first named subtype without constraints.  Your
progam won't be erroneous (because no range constraints will be violated),
and first named subtypes seem to be the only place where the size of
objects of that type match the value of size specified in the length clause
for the type.  (Readers: holler if this last statement is incorrect.)

>- Bob

-Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <mheaney-ya023180002709960713140001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>So the moral of the story is, if you're reading data off an interface, read
>it into a an object of a first named subtype without constraints.  ...

ANd make sure the first-named subtype matches the hardware data types.
E.g., use Interfaces.C.int.

- Bob

Re: Rules for Representation of Subtypes

[David C. Hoos, Sr.]

Matthew Heaney <mheaney@ni.net> wrote in article
<mheaney-ya023080002209961353500001@news.ni.net>...
> I've always been curious about the rules for representation of subtypes. 
> For example, if I make a declaration like this:
> 
>    A_Small_Integer : Integer range 0 .. 255;  -- assume type Integer is 4
bytes
> 
> then is an implementation allowed to use fewer than 4 bytes to represent
> A_Small_Integer?
> 
> Suppose I'm on a Unix system and I do this
> 
>    read (fd, A_Small_Integer'Address, 4);
> 
> If the representation of A_Small_Integer is only 1 byte, then obviously
I'm
> in trouble.  Am I required to specify the size of objects?
> 
>    A_Small_Integer : Integer range 0 .. 255;
>    for A_Small_Integer'Size use 32;                     -- required?
> 
> matt
> mheaney@ni.net
> 
> --------------------------------------------------------------------
> Matthew Heaney
> Software Development Consultant
> mheaney@ni.net
> (818) 985-1271
> 
Hi Matthew,

My understanding of the rules for representation clauses for types is that
the size attribute may only be specified for the first subtype, so for any
subtype of integer you would get the same size as Integer.
In fact, I just tried to specify a size of 8 bits for your object
"A_Small_Integer", with gnat 3.04a on Win95, and found that the compiler
gave no warning, and ignored the clause.  Printing out the 'size attribute
yielded 32.

However, as far as your "UNIX" example is concerned (I say "UNIX", because
this would apply to any OS where you're doing what you appear to be doing
here -- i.e. interfacing to the C library), why not write the code in a
manner where it doesn't matter how the compiler represents the object --
i.e., write:

    read (fd, A_Small_Integer'Address, A_Small_Integer'Size /
System.Storage_Unit);

The division is a compile-time operation, so there is no run-time
difference.

I hope this helps
-- 
David C. Hoos, Sr.,
http://www.dbhwww.com
http://www.ada95.com

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <01bba947$d8990620$188371a5@dhoossr.iquest.com>,
David C. Hoos, Sr. <david.c.hoos.sr@ada95.com> wrote:
>My understanding of the rules for representation clauses for types is that
>the size attribute may only be specified for the first subtype, so for any
>subtype of integer you would get the same size as Integer.

No, that's not quite right.  You're right about the rules for rep
clauses.  But that certainly does *not* imply that all subtypes of
integer have the same size as Integer -- you can't *ask* the compiler to
use 8 bits for a subtype of Integer, but the compiler can use 8 bits.
In fact, 13.3(55) requires that they do *not* have the same size, in
general.

Besides, the A_Small_Integer in the example was a variable, not a
subtype.  You can specify its size as 8 bits, if you want.  Or 32 bits.

Also, it's good to keep in mind that if you have subtype S and object X
of subtype S, it is NOT always the case that S'Size = X'Size.  In fact,
it is unusual for these to be equal.

>In fact, I just tried to specify a size of 8 bits for your object
>"A_Small_Integer", with gnat 3.04a on Win95, and found that the compiler
>gave no warning, and ignored the clause.  Printing out the 'size attribute
>yielded 32.

GNAT is not the definition of the Ada language.  ;-)

>However, as far as your "UNIX" example is concerned (I say "UNIX", because
>this would apply to any OS where you're doing what you appear to be doing
>here -- i.e. interfacing to the C library), why not write the code in a
>manner where it doesn't matter how the compiler represents the object --
>i.e., write:
>
>    read (fd, A_Small_Integer'Address, A_Small_Integer'Size /
>System.Storage_Unit);

Yes, that's better than "4".

- Bob

Re: Rules for Representation of Subtypes

[Samuel T. Harris]

David C. Hoos, Sr. wrote:
> i.e., write:
> 
>     read (fd, A_Small_Integer'Address, A_Small_Integer'Size /
> System.Storage_Unit);
> 

More safe (in a general sense) is ...

(A_Small_Integer'Size + System.Storage_Unit - 1) / System.Storage_Unit

... to handle those rare weird-sized entities with
involve non-zero remainders to the poster's division.

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

Re: Rules for Representation of Subtypes

[David C. Hoos, Sr.]

Samuel T. Harris <u61783@gsde.hso.link.com> wrote in article
<32474889.6EEA@gsde.hso.link.com>...
> David C. Hoos, Sr. wrote:
> > i.e., write:
> > 
> >     read (fd, A_Small_Integer'Address, A_Small_Integer'Size /
> > System.Storage_Unit);
> > 
> 
> More safe (in a general sense) is ...
> 
> (A_Small_Integer'Size + System.Storage_Unit - 1) / System.Storage_Unit
> 
> ... to handle those rare weird-sized entities with
> involve non-zero remainders to the poster's division.

You're absolutely correct, and I always code it that way.  Why I didn't put
it in my posting is probably because I don't desk-check e-mail and
newsgroup postings like I do real code -- with marker in hand and hard
copy.
-- 
David C. Hoos, Sr.,
http://www.dbhwww.com
http://www.ada95.com

Re: Rules for Representation of Subtypes

[Robert Dewar]

Matthew Heaney <mheaney@ni.net> wrote in article

  mheaney-ya023080002209961353500001@news.ni.net>...
   I've always been curious about the rules for representation of subtypes.
   For example, if I make a declaration like this:
  
      A_Small_Integer : Integer range 0 .. 255;  -- assume type Integer is 4
  ytes
  
   then is an implementation allowed to use fewer than 4 bytes to represent
   A_Small_Integer?
  
   Suppose I'm on a Unix system and I do this
  
      read (fd, A_Small_Integer'Address, 4);
  
   If the representation of A_Small_Integer is only 1 byte, then obviously
  'm
   in trouble.  Am I required to specify the size of objects?
  
      A_Small_Integer : Integer range 0 .. 255;
      for A_Small_Integer'Size use 32;                     -- required?
  
   matt
   mheaney@ni.net

David wrote

Hi Matthew,

  My understanding of the rules for representation clauses for types is that
  the size attribute may only be specified for the first subtype, so for any
  subtype of integer you would get the same size as Integer.
  In fact, I just tried to specify a size of 8 bits for your object
  "A_Small_Integer", with gnat 3.04a on Win95, and found that the compiler
  gave no warning, and ignored the clause.  Printing out the 'size attribute
  yielded 32.
  
  However, as far as your "UNIX" example is concerned (I say "UNIX", because
  this would apply to any OS where you're doing what you appear to be doing
  here -- i.e. interfacing to the C library), why not write the code in a
  manner where it doesn't matter how the compiler represents the object --
  i.e., write:
  
      read (fd, A_Small_Integer'Address, A_Small_Integer'Size /
  System.Storage_Unit);
  
  The division is a compile-time operation, so there is no run-time
  difference.
  
  I hope this helps

David's understanding is a bit confused, and so may not help :-)

This in fact is a place where Ada 95, somewhat accidentally, is incompatible
with most Ada 83 implementations. What Ada 95 did was to specify things that
are left unspecified in the Ada 83 reference manual, and to do it in a manner
that was compatible with the Intermetrics compiler, but not most other Ada
83 compilers, so this is something to be on the watch for.

David's first significant misunderstanding is that the size of an object
is not strongly related to the size of the type. So of course in GNAT, if
you specify the size of an object as 8, it will be 8, but this will not
affect the size of the type.

Second, in Ada 95, the size of a subtype is required to be the minimum
number of bits, so it is NOT AT ALL the case that a subtype has the same
size as the first subtype. On the contrary, this would be an incorrect
implementation.

For example, Natural'Size is required to be Integer'Size MINUS ONE, i.e.
31, not 32, on most machines. This can cause chaos if a program assumes
that Natural'Size is 32, as it was on many Ada 83 implementations.

In GNAT, we have implemented the Size attribute as described in the RM,
but generally the behavior of size is rather odd to most people:

   type x is range 1 .. 10;    -- x'size = 4
   subtype y is x range 1 .. 10; -- y'size = 4
   subtype z is x range 1 .. 9;  -- z'size = 4

Now use a size attribute clause

   type x is range 1 .. 10;    -- x'size = 16
   for x'size use 16;
   subtype y is x range 1 .. 10; -- y'size = 16
   subtype z is x range 1 .. 9;  -- z'size = 4
 
--
   Suppose I'm on a Unix system and I do this
  
      read (fd, A_Small_Integer'Address, 4);

Normally, you don't need to worry about the size of things, but if you
are interfacing to C, you ought to specify the size of the object, or in this
case, not simply use (A_Small_Integer'Size + Storage_Unit - 1)/Storage_Unit
for 4. This is similar to David's suggestion, except that he made an
unjustified assumption that the size of A_SMall_Integer would be a multiple
of Storage Unit.

Incidentally, we have considered adding an attribute Size_In_Storage_Units
to GNAT. It is annoyingly missing, and would often be useful.
                     

Re: Rules for Representation of Subtypes

[Keith Thompson]

In <dewar.843570543@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
[...]
> This in fact is a place where Ada 95, somewhat accidentally, is incompatible
> with most Ada 83 implementations. What Ada 95 did was to specify things that
> are left unspecified in the Ada 83 reference manual, and to do it in a manner
> that was compatible with the Intermetrics compiler, but not most other Ada
> 83 compilers, so this is something to be on the watch for.
[...]
> Second, in Ada 95, the size of a subtype is required to be the minimum
> number of bits, so it is NOT AT ALL the case that a subtype has the same
> size as the first subtype. On the contrary, this would be an incorrect
> implementation.
> 
> For example, Natural'Size is required to be Integer'Size MINUS ONE, i.e.
> 31, not 32, on most machines. This can cause chaos if a program assumes
> that Natural'Size is 32, as it was on many Ada 83 implementations.

The Ada 83 reference manual's description of the 'Size attribute is
rather vague.  AI-00536 was an attempt to clarify this description.
Among other things, it says:

        If the size of a type or a subtype S has not been determined by
        a length clause and S is either a scalar subtype, a constrained
        array subtype, a constrained subtype with discriminants, an
        access type, a task type, or a private type whose full type is
        one of these types, then S'SIZE yields the smallest number of
        bits that an implementation will allocate for an object declared
        with the subtype indication S; objects whose size is determined
        by a record component clause are not considered in determining
        the value of S'SIZE.

        For the predefined type BOOLEAN, BOOLEAN'SIZE is one.

In other words, the 'Size for a subtype is the smallest size that can be
allocated for an object of that subtype, including standalone objects
and components of (possibly packed) arrays and records, but excluding
components affected by record component clauses.

For an Ada 83 implementation that can pack a Natural and a Boolean into
a single word in a packed record, Natural'Size should be Integer'Size - 1.

Note in particular that Boolean'Size was required to be one, even though
a standalone Boolean object is very likely to occupy 8 bits or more.

I seem to recall that this interpretation was enforced by the 1.11 ACVCs,
though I don't remember the exact details.

Of the two Ada 83 implementations I have access to, one uses
Natural'Size=31.  The other uses Natural'Size=32, but it doesn't support
pragma Pack on records.

(Publicly disputing Robert Dewar is always dangerous.  Fortunately it's
a bounded error; the effect is limited to learning something.)

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL

Re: Rules for Representation of Subtypes

[Matthew Heaney]

In article <DyC5xn.K3L@thomsoft.com>, kst@thomsoft.com (Keith Thompson) wrote:

>The Ada 83 reference manual's description of the 'Size attribute is
>rather vague.  AI-00536 was an attempt to clarify this description.
>Among other things, it says:
>
>        If the size of a type or a subtype S has not been determined by
>        a length clause and S is either a scalar subtype, a constrained
>        array subtype, a constrained subtype with discriminants, an
>        access type, a task type, or a private type whose full type is
>        one of these types, then S'SIZE yields the smallest number of
>        bits that an implementation will allocate for an object declared
>        with the subtype indication S; objects whose size is determined
>        by a record component clause are not considered in determining
>        the value of S'SIZE.
>
>        For the predefined type BOOLEAN, BOOLEAN'SIZE is one.
>
>In other words, the 'Size for a subtype is the smallest size that can be
>allocated for an object of that subtype, including standalone objects
>and components of (possibly packed) arrays and records, but excluding
>components affected by record component clauses.

Yes, but what's even more interesting is a preceding paragraph of that AI
which states:

"If the size of a type of a first named subtype T has been specified by a
length clause, the T'Size yields the specified size, AND THE SIZE OF EVERY
SUBTYPE OF T IS ALSO THIS VALUE [my emphasis]."

If my interpretation is correct (I'm waiting for an opinion, Bob...), then
this would solve my original problem, which was

   type Integer_32 is ...;
   for Integer_32'Size use 32;

   subtype T is Integer_32 range 0 .. 255;

   O : T;

According to the AI, object O should occupy 32  bits, not 8.  Right?

>Keith Thompson (The_Other_Keith) kst@thomsoft.com

matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <mheaney-ya023180002609962246250001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>"If the size of a type of a first named subtype T has been specified by a
>length clause, the T'Size yields the specified size, AND THE SIZE OF EVERY
>SUBTYPE OF T IS ALSO THIS VALUE [my emphasis]."
>
>If my interpretation is correct (I'm waiting for an opinion, Bob...), then
>this would solve my original problem, which was

I'm not sure if I'm the Bob being addressed, but...   I think your
interpretation is correct.  However, in Ada 95, such a rule can't work.
Consider:

    type T is range 0..15;
    for T'Size use 4;
    subtype Bigger is T'Base range -15..15;

Clearly, Bigger'Size cannot be 4.

Also, note that the size of an object can be bigger than the size of its
subtype (in both Ada 83 and 95).  In other words, specifying the size of
an object gives much more exact control, and is desirable in many
low-level situations (despite the fact that it is rather verbose).

Also, any rule that begins "if the so-and-so attribute is specified..."
is suspect, because you don't want the meaning of 'Whatever to depend on
whether the user chose it or the compiler chose it.  For example, if I
print out Foo'Whatever, and find out it's 123, and then I add "for
Foo'Whatever use 123;", the meaning of my program shouldn't change.

Unfortunately, though, Robert is correct that the new rules cause some
problems with porting code from Ada 83 to Ada 95.  On the other hand,
there were already problems porting between Ada 83 compilers, so I don't
know.  Sigh.

The Java language designers had it much easier -- they simply say that
the predefined types are 8, 16, 32, and 64 bits, and if you're running
on a 36-bit machine, tough.

- Bob

Re: Rules for Representation of Subtypes

[Robert Dewar]

Bob said

"I'm not sure if I'm the Bob being addressed, but...   I think your
interpretation is correct.  However, in Ada 95, such a rule can't work.
Consider:

    type T is range 0..15;
    for T'Size use 4;
    subtype Bigger is T'Base range -15..15;

Clearly, Bigger'Size cannot be 4.
"



This is a baby and bathwater case!

Yes, of course the rule cannot apply to the unusual case of Bigger here, but
that is NOT a sufficient reason to throw out the entire rule, causing
incompatibilities.

In GNAT, we regard Bigger as a subtpye of the base type of T, not a subtype
of T for the purposes of the size ingheritance rules that apply to object
size (which is like the old Ada 83 size).

Re: Rules for Representation of Subtypes

[Robert Dewar]

Matthew says

""If the size of a type of a first named subtype T has been specified by a
length clause, the T'Size yields the specified size, AND THE SIZE OF EVERY
SUBTYPE OF T IS ALSO THIS VALUE [my emphasis].""

This is an Ada 83 AI. For whatever  reasons, the Ada 95 RM does not follow
this AI, or permit compilers to follow it. RM 95 requires that subtypes
have a different size from the first subtype if the range is static and
a smaller type is possible.

Re: Rules for Representation of Subtypes

[Robert A Duff]

In article <DyC5xn.K3L@thomsoft.com>, Keith Thompson <kst@thomsoft.com> wrote:
>I seem to recall that this interpretation was enforced by the 1.11 ACVCs,
>though I don't remember the exact details.

I don't think so, since I know at least one Ada 83 compiler (validated)
had Boolean'Size = 8.

- Bob

Re: Rules for Representation of Subtypes

[Robert Dewar]

I meant to add more on the issue of Size, but accidentally termianted
transmission early!

One thing we have done in GNAT is the following:

First, objects of a subtype by default have the same size as the size
of the first subtype, even though Ada 95 does NOT require this, and in
fact makes an implementation suggestion to the contrary:

50   If the Size of a subtype is specified, and allows for efficient
independent addressability (see 9.10) on the target architecture, then the
Size of the following objects of the subtype should equal the Size of the
subtype:

   51  Aliased objects (including components).

   52  Unaliased components, unless the Size of the component is
       determined by a component_clause or Component_Size clause.


We at first followed this advice and found it caused compatibility chaos!
So, that's the first point, David's guess as the the behavior of subtypes
is in fact corect WITH RESPECT TO OBJECTS in GNAT. This is of course in the
absence of a specific attribute representation clause. 

Second, we have provided two new attributes

Value_Size is just like Size in the RM, except that it can be applied to
subtypes other than the first subtype. 

Object_Size is the size that will be used by default for objects of the
type or subtype. It need not be the same as Value_Size. The default value
of Object_Size is close to what most Ada 83 compilers provided for Size.
It can be specified for subtypes other than the first subtype.

Value_Size, like Size in the RM, is used for packing and for unchecked
conversion, but not much else.