Re: The Incredible Shrinking Type

[Robert Dewar <robert_dewar@my-deja.com>]

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.