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. MY RESPONSE: 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 the object." 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?