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
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
I'm sorry, but this is only partly true.
Ada '83: "X'SIZE Applied to an object, yields the number of bits
allocated to hold the object. ..."
Ada '95: "X'Size Denotes the size in bits of the representation of
In Ada Issue AI-00536, the Ada '83 language was clarified with a binding
interpretation that said (among other things): "...This number may
include padding bits that are part of the stored value....For the
predefined type Boolean, BOOLEAN'SIZE is one. An implementation shall
describe, in Appendix F, how the value of 'SIZE is determined...."
I suspect that the "may" was put in to warn users of how compiler
vendors had misinterpreted the intent. Too late to close the door, just
let everyone know the cows are out.
In Ada '95, the language was made a little more precise but the meaning
(of the original intent) was not changed. In my opinion, eliminating
portability problems that were never intended to occur was not "poor
form." Poor form is accusing them of moving an error detection from
compile-time to run-time when one of the general goals of the revision
was the opposite. The truth is, Rational now detects an error at
run-time that was not detected at all before.
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
So we were just lucky in the past that Rational (probably
unintentionally) took advantage of looseness in the definition of Ada
and in the process, compensated for our coding error.
I do agree with [his] recommendation: We should search our code for
other instances of this error, and correct them.
Ada is not perfect. The designers and reviewers of Ada '95 are human,
therefore must have made mistakes. A very few of those mistakes are
still in the language---this is not one of them. We should just be glad
that 95-99% of the mistakes were discovered by expert reviewers (instead
of by the users, as with today's three most popular languages).
DID MY RESPONSE MISINTERPRET ANYTHING?