Packing Records Using Size Attribute Definitions Clauses

Packing Records Using Size Attribute Definitions Clauses

[Charles H. Sampson]

     Did something happen between Ada 83 and Ada 95 affecting the abil-
ity to pack a record by using a Size attribute definition clause?  This 
is not one of the advertised incompatibilities, but I've tried my code 
on three Ada 95 compilers and they all reject it.

     Here are the details.  The components of the record are numeric 
(integer and fixed-point), with one exception.  The types of the numeric 
components have size attribute clauses specifying either 16 bits or 32 
bits, with two exceptions.  The two exceptional numeric component types 
have size attribute clauses specifying 7 and 9 bits and the correspond-
ing components are consecutive in the source.  The non-numeric component 
is of a record type and this type has a representation specification and 
a size attribute clause that specifies it as 16 bits.  The minimum size 
for the big record type (the one I'm having a problem with) is 464 bits.  
It has a size attribute clause for this size.  Everything sails through 
our Ada 83 compiler.

     GNAT, ObjectAda, and Green Hills are all unhappy with this, claim-
ing that 464 bits is not enough, although they don't agree on how many 
bits are needed.  However, when I throw in a record representation 
specification that maps the components in the obvious fashion (leaving 
in the size attribute clause), all three compilers are happy.

     Maybe I'm being naive, but if the representation is legal 
shouldn't at least one of the compilers have found it on its own?  At 
the very least, why should they be telling me that 464 bits are not 
enough when all you have to do is add up the lengths of the components?

     But I don't want this post to be a compiler gripe.  Would somebody 
please point me to the part of the LRM that explains this behavior.  If 
the issue has already been discussed to death, then a pointer to the 
thread on Deja News would be fine.  (I've already searched c.l.a using 
(size & (attribute | specification | spec)) and haven't found anything.)

				Charlie
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Packing Records Using Size Attribute Definitions Clauses

[Tucker Taft]

Charles H. Sampson (claveman@fern.mil) wrote:

:      Did something happen between Ada 83 and Ada 95 affecting the abil-
: ity to pack a record by using a Size attribute definition clause?  This 
: is not one of the advertised incompatibilities, but I've tried my code 
: on three Ada 95 compilers and they all reject it.

Yes.  A size clause is not the way to cause a record to be packed in Ada 95.
The pragma "pack" is for that.  A size clause is a way to effectively
"confirm" that the record is the size you think it should be,
or perhaps to pad it out, but it is not the way to shrink it.
See RM95 13.3(53).

A size clause had an indirect effect of causing packing on
some, but not all, Ada 83 compilers.  In Ada 95, the pragma
Pack is for packing.

: ...
:      But I don't want this post to be a compiler gripe.  Would somebody 
: please point me to the part of the LRM that explains this behavior.  If 
: the issue has already been discussed to death, then a pointer to the 
: thread on Deja News would be fine.  (I've already searched c.l.a using 
: (size & (attribute | specification | spec)) and haven't found anything.)

As mentioned above, RM95 13.3(53) makes it clear that a Size clause
is not designed to alter the internal layout of a composite type.
If you have the annotated RM, you will find that paragraph 53a suggests
the use of pragma Pack, a record_representation_clause for a record, 
or a component_size clause for an array, to control the internal layout.

: 				Charlie
: --
: ******

:      For an email response, my user name is "sampson" and my host
: is "spawar.navy.mil".

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: Packing Records Using Size Attribute Definitions Clauses

[dewarr]

In article <F2nEKI.3s6.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> Charles H. Sampson (claveman@fern.mil) wrote:
>
> :      Did something happen between Ada 83 and Ada 95
affecting the abil-
> : ity to pack a record by using a Size attribute
definition clause?  This
> : is not one of the advertised incompatibilities, but
I've tried my code
> : on three Ada 95 compilers and they all reject it.
>
> Yes.  A size clause is not the way to cause a record to
be packed in Ada 95.
> The pragma "pack" is for that.  A size clause is a way to
effectively
> "confirm" that the record is the size you think it should
be,
> or perhaps to pad it out, but it is not the way to shrink
it.
> See RM95 13.3(53).


The yes in Tuck's message is wrong here. There has been no
change in the relevant language features between Ada 83
and Ada 95.

Both language definitions recommend against implementations
allowing implicit packing via the size clause, but do not
prohibit this (highly undesirable) behavior.

The difference is that in Ada 95, this implementation
advice is explicit, in Ada 83 it was implicit (deducible
from the intent of the RM, but not explicit. This was
discussed in one of the Ada 83 AI's).

Unfortunately, some Ada 83 compilers unwisely ignored the
relevant AI and allowed this implicit packing with the
result that in some cases you can get expensive implicit
conversions happening, something that Ada was designed to
avoid (that is indeed how you can deduce the intent in
Ada 83 that such implicit packing should not occur!)

In the Ada 95 world, compilers are behaving in a more
reasonable manner. Use pragma Pack if you want to Pack!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Packing Records Using Size Attribute Definitions Clauses

[bob]

To augment this a little, what Mr. Dewar says is correct. In generating
records for TCP/IP transfer, the VERDIX (Now Rational) Ada83 compiler very
often does implicit compaction both on types and subtypes (surprise). This
led us to quite a few hours of debugging data streams which started one way
and ended up at the other end quite differently.
Thanks for the predictability of the Ada95 implementations, some of these
were found by rebuilding with GNAT and checking the results. Why didn't we
use GNAT in the first place? It didn't exist when we started, but we are
working on this right now.

cheers...bob

dewarr@my-dejanews.com wrote in article
<73589m$pnj$1@nnrp1.dejanews.com>...
> In article <F2nEKI.3s6.0.-s@inmet.camb.inmet.com>,
>   stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> > Charles H. Sampson (claveman@fern.mil) wrote:
> >
> > :      Did something happen between Ada 83 and Ada 95
> affecting the abil-
> > : ity to pack a record by using a Size attribute
> definition clause?  This
> > : is not one of the advertised incompatibilities, but
> I've tried my code
> > : on three Ada 95 compilers and they all reject it.
> >
> > Yes.  A size clause is not the way to cause a record to
> be packed in Ada 95.
> > The pragma "pack" is for that.  A size clause is a way to
> effectively
> > "confirm" that the record is the size you think it should
> be,
> > or perhaps to pad it out, but it is not the way to shrink
> it.
> > See RM95 13.3(53).
> 
> 
> The yes in Tuck's message is wrong here. There has been no
> change in the relevant language features between Ada 83
> and Ada 95.
> 
> Both language definitions recommend against implementations
> allowing implicit packing via the size clause, but do not
> prohibit this (highly undesirable) behavior.
> 
> The difference is that in Ada 95, this implementation
> advice is explicit, in Ada 83 it was implicit (deducible
> from the intent of the RM, but not explicit. This was
> discussed in one of the Ada 83 AI's).
> 
> Unfortunately, some Ada 83 compilers unwisely ignored the
> relevant AI and allowed this implicit packing with the
> result that in some cases you can get expensive implicit
> conversions happening, something that Ada was designed to
> avoid (that is indeed how you can deduce the intent in
> Ada 83 that such implicit packing should not occur!)
> 
> In the Ada 95 world, compilers are behaving in a more
> reasonable manner. Use pragma Pack if you want to Pack!
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own  
 
> 

Re: Packing Records Using Size Attribute Definitions Clauses

[Charles H. Sampson]

     Many thanks to all for these responses.  In particular, Tucker's 
reference to 13.3(53) seems to be the crucial point I was missing, at 
least after I ran down what "internal layout" means.

     I certainly have no disagreement with the main point made, that a 
size clause is not the way to cause records to be packed.  (I inherited
the code I'm porting, so it can't be blamed on me.)  I never understood
the purpose of that feature of Ada 83.  I can't conceive of a case in 
which I would want to specify the amount of memory allocated to a record
but I wouldn't particularly care where its components were.  Can anybody
think of a use for such a thing?

     On the other hand, I disagree with Robert's assertion that packing
by means of size clauses was not intended in Ada 83.  Certainly he is 
far more qualified than I to speak of intent, being active while the de-
tails of the language were being hammered out.  I have to rely on what 
was written in the LRM and when I read, "The value of the expression 
specifies an upper bound for the number of bits to be allocated to ob-
jects of the type ..." and "A size specification for a composite type 
may affect the size of the gaps between the storage areas allocated to 
consecutive components" it sounds a lot like packing.  (He does refer to
an AI on the subject and AI-0553 looks like it might be the one, based 
on its title.  I'd like to read it, but I can't find it.  Are they still
available somewhere?  I deleted those I had only a few months ago.)

     Whatever.  The upshot is that I have an unexpected source change to
make while I'm porting the code.  Not a big thing, but something of a 
surprise.

                                Charlie

-- 
     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".