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?