comp.lang.ada
 help / color / mirror / Atom feed
From: Robert Dewar <robert_dewar@my-deja.com>
Subject: Re: The Incredible Shrinking Type
Date: 2000/11/07
Date: 2000-11-07T00:00:00+00:00	[thread overview]
Message-ID: <8ua3d6$bn0$1@nnrp1.deja.com> (raw)
In-Reply-To: 3A08092F.E369B323@earthlink.net

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.




      reply	other threads:[~2000-11-07  0:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-06  0:00 The Incredible Shrinking Type Marc A. Criley
2000-11-07  0:04 ` Robert Dewar
2000-11-07  0:00   ` Nicolas Brunot
2000-11-07  0:00     ` Robert Dewar
2000-11-08  0:00       ` Nicolas Brunot
2000-11-09  5:41         ` Robert Dewar
2000-11-07  0:00   ` Marc A. Criley
2000-11-07  0:00     ` Robert Dewar [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox