TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Mon, 19 Oct 1998 16:43:43 +0200
text/plain; charset=us-ascii
ELCA Matrix SA
Mats Weber <[log in to unmask]>
text/plain (57 lines)
W. Wesley Groleau x4923 wrote:
> I met a guy who is definitely anti-Ada and pro-C.  Unfortunately, he is
> now a support person for an Ada vendor.  Recently he responded to a bug
> report as follows:
>   I have researched this problem and find that the designers of the Ada
>   language changed the meaning of the Size attribute.  Basically, the
>   difference is that Ada 83 gave you the size of the storage container and
>   Ada 95 gives you the size of the bits of actual interest.  As what is
>   normally wanted for programming purposes is the number of bytes, the Ada
>   83 construction X'Size/8 was just fine.  To get the same result in Ada
>   95, what is wanted is (X'Size+7)/8.  For any customer converting from
>   Ada 83 to Ada 95, this is a problem because it shows up in small print
>   in the middle of hundreds of pages that only a compiler-writer could
>   love.
>   We can argue about the poor form of the Ada 95 designers to change the
>   meaning of something, essentially postponing error detection to runtime,
>   but the solution is simple. Any project converting from Ada 83 to Ada 95
>   should grep over their source tree and examine any uses of 'Size.
>   I do not anticipate any change to alleviate the impact of the language
>   designers decision.  The only change I believe we might see, not in a
>   short timeframe, would be to add a [vendor-specific] attribute something
>   like X'Size83.  Either way, source code would need to be examined and
>   changed.

This guy is right regarding the consequences of the change in the definition
of 'Size in Ada 95 (I have converted programs and it really is a pain). He is
wrong when he says that 'Size has changed between '83 and '95: it was
underspecified in '83, and the compilers I have been using were making an
interpretation that is defferent from the one that got standardized (bad luck
? :-).


>   The real problem is that Object'Size/8 was never the correct way to find
>   the number of octets an object had bits in.  In all dialects of Ada,
>   integer division truncates.  Therefore:
>   Object'Size    Object'Size/8  (Object'Size+7)/8
>        1                0                 1
>        5                0                 1
>        7                0                 1
>        8                1                 1
>        9                1                 2

I think you are missing the difference between Type'Size and Object'Size in
Ada 95. Type'Size is the minimal required size in a packed record, and
Object'Size is something else, and should be a multiple of the type's
alignment (I recommend you re-read RM 13.3). Note that Object'Size will almost
never be 1, 5, 7 or 9 as in your table above, but Type'Size could.

Anyway, 'Size is still not good enough in all situations. I have had to use
GNAT's vendor specific 'Object_Size in some cases.