The Incredible Shrinking Type

The Incredible Shrinking Type

[Marc A. Criley]

The following program exhibits what is, to me, somewhat unexpected behavior.  I
define an overly long type by applying a size attibute of 72 bits.  The Linux
GNAT compiler (3.13) allocates 128 bits for objects of this type, which is a
reasonable thing for it to do.

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?

--------------------------------------------------------------
with System;
with Text_IO; use Text_IO;

procedure Chk_Size is

   type Modest_Type is range 0..99;
   for Modest_Type'Size use 72;

   MT : Modest_Type;

   procedure Dump_Size(Param : Modest_Type) is
   begin
      Put_Line("Param'Size is" & Natural'Image(Param'Size));
   end Dump_Size;

begin
   Put_Line("Modest_Type size: " & Natural'Image(Modest_Type'Size));
   Put_Line("MT obj size:      " & Natural'Image(MT'Size));

   Dump_Size(MT);

end Chk_Size;
--------------------------------------------------------------

Compiling this does generate the warning:

chk_size.adb:7:29: warning: 64 bits of "Modest_Type" unused

Running it produces:

Modest_Type size:  72
MT obj size:       128
Param'Size is 64


Marc A. Criley

Re: The Incredible Shrinking Type

[Robert Dewar]

In article <3A0816D4.E980EAFB@cadwin.com>,
  Nicolas Brunot <n.brunot@cadwin.com> wrote:

> and certainly not improve portability required by the RM.

The only thing that the RM has to say here is that portable
code must NOT assume anything about the size of parameters,
since there is no way to specify it!

So there is definitely no portability requirement here
(other than to avoid making the assumptions).

Most portability problems in Ada are caused by bogus
assumptions of this kind. Yes it may be odd that the
parameter size is 64 rather than 128 here, but there
is definitely nothing in the RM that suggests otherwise
(let alone requiring otherwise).


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The Incredible Shrinking Type

[Robert Dewar]

In article <3A08092F.E369B323@earthlink.net>,
  "Marc A. Criley" <mcquad@earthlink.net> wrote:
> However, today, the last of the residual reluctance has
> finally been cleared away...and I do believe! :-)

The real actuality is that compilers will generally let
type'size influence object'size where it makes reasonable
sense. Certainly we don't expect compilers to try to allocate
5-bit objects (though amazingly the old Alsys compilers did
just that). On the other hand if we say one type is 8 bits
and one type is 16 bits, and we are on a byte addressed
machine, it would be most surprising if we did not get
8 bits and 16 bits for objects respectively (GNAT allows
you to force this with Object_Size if necessary).

However, for strange things like this type with padding,
bets are off. Generally the notion in GNAT is that a parameter
size corresponds to the size of the value not the size of
the allocated object, that for example makes a very big
difference with variant records, and most programs assume
that you get the size of the particular variant represented
by the parameter, rather than the allocated size of the
object, which can of course be larger.

The RM has little to say here in this rather significant
choice, we just go by what Ada 83 compilers seem to do
in practice.

Note that you should never assume too much about the size
of parameters, since the compiler is free to choose, and
there is no way to override it in Ada 95 for parameters.


>
> >
> > 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).
> >
>
> I agree this is a peculiar use.  Fortunately I'm not employing
that
> technique, I just want to be able to properly and accurately
analyze any
> such peculiar software that I may come across.
>
> Marc A. Criley
> Senior Staff Engineer
> Quadrus Corporation
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The Incredible Shrinking Type

[Nicolas Brunot]

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.

Re: The Incredible Shrinking Type

[Marc A. Criley]

Robert Dewar wrote:
> 
> 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.

Actually I do understand the distinction between the sizes of a type and
objects of that type. That's been very well beaten into me over the last
couple years.  In my case, I guess there's still been a residual
reluctance to accept that specifying the size of a type only affects
packing and Unchecked_Conversion. Especially since compilers do usually
try to utilize that size (in some way, as demonstrated in the example)
when allocating objects of that type--implying there is a semantic
effect beyond those two areas.

However, today, the last of the residual reluctance has finally been
cleared away...and I do believe! :-)

> 
> 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).
> 

I agree this is a peculiar use.  Fortunately I'm not employing that
technique, I just want to be able to properly and accurately analyze any
such peculiar software that I may come across.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation

Re: The Incredible Shrinking Type

[Robert Dewar]

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.

Re: The Incredible Shrinking Type

[Nicolas Brunot]

> <So there is definitely no portability requirement here, (other than
> to avoid making the assumptions).>

Nobody said that, except you justifying type shrinking by RM requiring
portability ...

> <Yes it may be odd that the parameter size is 64 rather than 128 here>

Odd is not the right word, unexpected, unsafe or illogical would be more
appropriate

> <is definitely nothing in the RM that suggests otherwise (let alone
> requiring otherwise).>

Right, the "normal" behavior (without shrinking) would just be suggested
by common sense, and also ... by gnat documentation itself ...

Re: The Incredible Shrinking Type

[Robert Dewar]

In article <3A091116.75D56C2A@cadwin.com>,
  Nicolas Brunot <n.brunot@cadwin.com> wrote:
> > <So there is definitely no portability requirement here,
(other than
> > to avoid making the assumptions).>
>
> Nobody said that, except you justifying type shrinking by RM
requiring
> portability ...
>
> > <Yes it may be odd that the parameter size is 64 rather than
128 here>
>
> Odd is not the right word, unexpected, unsafe or illogical
> would be more appropriate

Unexpected -- you have no basis for expecting anything
Unsafe -- If your code depends on your unwarranted expectations,
          then it is your code that is unsafe!
Illogical -- Well I can't be responsible for people's logic. As
             I explained in a previous note, our convention for
             parameter'Size, based on what we see most Ada 83
             compilers doing, is to have this query return the
             actual size used by the value, rather than the
             allocated size of the object.

Consider why we do this. Suppose you have the following:


   x : integer;
   for x'size use 32;

   y : integer;
   for y'size use 64;

   procedure p (m : in integer) is
   begin
      Put (m'size);
   end;

   ...

   p(x);
   p(y);

DO you really expect (accordingly to your logic) to see 32
and 64 here? If you do, you are asking for an amazing overhead
to be added to all procedure calls, namely an extra hidden
parameter for every parameter giving the allocated length of
the calling object. Surely you don't expect this ...

> Right, the "normal" behavior (without shrinking) would just be
> suggested by common sense

Common sense has no place in this discussion if it is not
backed up by the RM. The RM is the *only* thing you can rely
on here. I cannot tell you how many portability problems are
caused by programmers who rely on their common sense rather
than an exact knowledge of what is and is not guaranteed by
the definition of the language.

> and also ... by gnat documentation itself ...

Not sure what you are referring. Please provide quote here.

Note that in all this discussion, this is a VERY strange type
to define in the first place, which is why it generates a
warning that there are unused bits. The whole purpose of this
warning is to warn that there are bits in the allocated object
that do not participate in any way in what is going on!

The rules about parameters in GNAT are really intended for the
variant record case, where there really is an issue, and as I
mentioned before, the RM leaves open whether 'Size on a variant
record parameter returns the allocated size or the actual
size. We chose the latter because Ada 83 compilers seem to have
made that choice (there is a section in the GNAT RM that
specifically discusses this).


Sent via Deja.com http://www.deja.com/
Before you buy.