CVS difference for ais/ai-00319.txt
--- ais/ai-00319.txt 2002/10/10 17:14:40 1.1
+++ ais/ai-00319.txt 2002/10/10 17:41:47 1.2
@@ -8,8 +8,7 @@
-A new attribute, 'Object_Size, is defined to cleanly the representation of
+The new attribute S'Object_Size denotes the size of most objects of subtype S.
@@ -66,8 +65,8 @@
that implementations that do not round up allocations (just using padding
to provide alignment) are not required to do any rounding up.
-If X denotes an object (including components) of S, X'Size should S'Object_Size,
+If X denotes an object (including components) of subtype S, X'Size should
+be S'Object_Size, unless:
X'Size is specified; or
The size of X is determined by a component_clause or Component_Size clause; or
Pragma Pack applies to the type containing component X.
@@ -109,8 +108,25 @@
subtypes. We allow this freedom, as Rational^H^H^H^H^H^H^H^H some
implementations may have trouble with static matching if the Object_Sizes
of subtypes can be different (see 4.9.1). We will let the market decide
- of subtype specification of Object_Size is necessary.
+ whether subtype specification of Object_Size is necessary.
+Change 13.3(50) to:
+If the Object_Size of a subtype is not specified, the Size of the subtype is
+specified, and allows for efficient independent addressability (see 9.10) on
+the target architecture, then the Size of the following objects of the subtype
+should equal the Size of the subtype:
+ Ramification: If Object_Size is specified, this rule does not apply; the
+ rules for Object_Size apply instead. If Object_Size is not specified,
+ this rule implies that the default Object_Size is the same as the
+ specified Size if the Size allows for efficient independent addressability
+ (which, BTW, is not defined in 9.10).
+ Reason: We need to specify what happens if both Object_Size and Size are
+ specified incompatibly.
Change the first sentence of 4.9.1(2) to:
A subtype statically matches another subtype of the same type if they have
@@ -307,5 +323,124 @@
> (Object_Size has only a weakly suggested value, so it is likely that
> T'Object_Size = T'Base'Object in the absense of a specification for
+From: Randy Brukardt
+Sent: Thursday, October 10, 2002 12:28 AM
+> > -- Requiring subtype specifiability would simplify the wording some, but
+> > I believe that Rational would scream bloody murder (because that would
+> > force a legality check to depend on representation). Any ideas on
+> > avoiding that trap? (The discussion of AI-109 would suggest that there
+> > is not);
+> I spent years arguing about this point with Robert Dewar.
+> I think I'll say "no comment" this time. ;-)
+Ah, you've just been waiting years for some other poor sucker to take a
+crack at this. :-) :-)
+> > A new attribute, 'Object_Size, is defined to cleanly the representation of
+> > subtypes.
+> Last clause no verb. ;-)
+> At first I thought you meant "specify", but the normal RM style sort of
+> assumes that attributes' primary purpose is to *query*. So how about
+> something like "The new attribute S'Object_Size denotes the size of
+> certain objects of subtype S." (I know S'Object_Size is an
+> attribute_reference, not an attribute, but we can be informal here.)
+I've used your wording.
+> > For every subtype S:
+> > S'Object_Size If S is definite, denotes the size (in bits) that the
+> > implementation would choose for the following objects of subtype S:
+> > * A stand-alone object of subtype S.
+> > * A record component of subtype S when the record type has
+> > no representation items applied.
+> > * An array component of subtype S when the array type has
+> > no representation items applied.
+> Hmm. This seems to require that all of these kinds of objects must be
+> the same size. I have the impression that some compilers don't do that
+> currently, and they should not be forced to change. (I think some
+> compilers pack arrays and maybe records more tightly than stack frames.
+I don't know, but it certainly is my intent that they be the same. Else we
+have the same problem that we have with 'Size (it doesn't mean anything).
+We'll need to talk about this.
+> > We purposely used the vague phrase "consistent with the alignment of S"
+> > so that implementations that do not round up allocations (just using
+> > padding to provide alignment) are not required to do any rounding up.
+> I didn't find the term "vague" until you said it was. I understood it
+> to mean precisely, "S'Object_Size shall be a multiple of S'Alignment".
+Because you use that strange model that requires something with an alignment
+of 4 to have a size that is a multiple of it. I (and Janus/Ada) do not use
+such a model. (A byte can have alignment 4, there is no problem with that
+IMHO). In our compiler, "consistent with the alignment of S" has no effect.
+So the phrase means whatever makes sense to the implementation. And that's
+> I'm not sure *any* advice is wise, here. The above appears to give
+> advice on the value of 'Object_Size, but it's really indirectly giving
+> advice on how to lay out objects. I think compilers should be free to
+> do what they like (when 'Object_Size is not specified). Certainly any
+> such advice should not contradict what any existing compilers do.
+It's ADVICE for a reason. Compilers should be free to ignore it if it makes
+sense. That's true of all ADVICE.
+> Anyway, why give advice if it doesn't say anything (as the above
+> vagueness claim seems to be saying)?
+No, it says quite a bit. It just doesn't say exactly what alignment rule a
+compiler is going to use, because that is silly (I think the rule that you
+guys use is silly, but I don't see any reason to suggest that you change).
+> I presume the above advice is *not* intended to be "Recommended Level of
+> Support" -- i.e., it remains "merely" advice even in the Systems Prog
+Correct. That's why it doesn't use that phrase.
+> > If S is a static signed integer subtype, the implementation should
+> > support specifying S'Object_Size to be the size of any signed integer
+> > base type provided by the implementation that is at least as large
+> > as S'Size.
+> No such thing as "base type". Why say all this anyway? Why not just
+> say something about "naturally supported by the hardware"?
+Because that NOT what Annex B says about Interfaces, and this ought to be
+consistent with that. I'm fairly confident that this is wrong anyway,
+because of signed/unsigned issues. I'm going to have to revisit it, but no
+> > Change the first sentence of 4.9.1(2) to:
+> > A subtype statically matches another subtype of the same type if they have
+> > statically matching constraints and their Object_Sizes (see 13.3) are the
+> > same.
+> This seems like a loophole. Shouldn't the *default* 'Object_Size be
+> required to be the same for subtypes of the same type with statically
+> matching constraints?
+That's required by 13.1(15/1); if it isn't, that paragraph should be fixed
+to do so (that is part of AI-109, but I doubt that AI will ever be
+I've noticed another problem as well: I didn't say what happens when both
+Object_Size and Size are specified incompatibly. I've fixed that in draft
+/02. It will be posted on the web site momentarily. (Along with all other
+changes to date.)
Questions? Ask the ACAA Technical Agent