Re: The Incredible Shrinking Type

[Nicolas Brunot <n.brunot@cadwin.com>]

I don't see any confusion here between the size of a type with the size
of objects of the type, since I read
<GNAT compiler (3.13) allocates 128 bits for objects of this type, which
is a reasonable thing for it to do.>

Shrinking the type seems in any case quite a dangerous thing to do,
since what is done here is quite common when you want to map an Ada
record type to a C type, without using all the components of the C type.

There will certainly be execution crash if C code try to access the bits
you don't use in Ada.

More than that, reading Gnat documentation, you are more likely to
expect a bigger size for the object, which is not big deal, than a
shrinking, which is everything but safe, and certainly not improve
portability required by the RM.

Robert Dewar a �crit :

> In article <3A0703F5.9333AE56@earthlink.net>,
>   "Marc A. Criley" <marccriley@earthlink.net> wrote:
>
> > However, when passing an instance of this type as a parameter
> to a procedure and
> > extracting its 'Size, the result is 64.  What happened to the
> rest of the bits?
> > Granted, they were unused, but still...  Where is this
> behavior addressed by the
> > language (if it is), or is it a freedom granted to compiler
> implementor's?
>
> You are making the common mistake of confusing the size of
> a type with the size of objects of the type. Specifying the
> size of a type only affects packing and unchecked conversion
> in Ada 95 semantics. It does not determine the size of
> objects of the type, and there is no requirement that the
> size of all objects of the type be the same.
>
> So the real issue here is what you have read in the RM that
> implies that the above behavior is expected or not expected.
> Actually asking for more than 64 bits for a scalar type is
> a bit peculiar anyway (and way out of the portable behavior
> required by the RM).
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.