CVS difference for ais/ai-00109.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00109.txt

--- ais/ai-00109.txt	1999/03/22 23:00:33	1.2
+++ ais/ai-00109.txt	1999/11/29 21:14:21	1.3
@@ -1,4 +1,4 @@
-!standard 13.03    (55)                               99-03-22  AI95-00109/06
+!standard 13.03    (55)                               99-11-29  AI95-00109/07
 !class binding interpretation 96-04-04
 !status work item 98-04-01
 !status ARG Approved (subject to letter ballot)  7-0-3  97-11-14
@@ -11,7 +11,7 @@
 !difficulty Hard
 !subject Size and Alignment Attributes for Subtypes
 
-!summary 99-03-22
+!summary
 
 This AI addresses issues related to Size and Alignment attributes for
 subtypes.  For Size and Alignment of objects, see AI95-00051.
@@ -27,12 +27,31 @@
     record or array does not fit in a single word, the Size may be
     rounded up, but not past the next word boundary.
 
-    The implementation need not support an Alignment clause for a
-    subtype unless the Alignment evenly divides the size (in storage
-    elements) that the implementation would normally choose for objects
-    of the subtype.  For indefinite subtypes, the smallest such size is
-    used.
+    13.3(31) is replaced by:
 
+    For a subtype that satisfies 13.1(23), the implementation need not support
+    an Alignment clause unless:
+
+        - For record types and type extensions: The size in storage elements
+          is a multiple of the Alignment.
+
+        - For arrays: This advice is applied recursively to the component
+          subtype.
+
+        - For a signed integer subtype, the Alignment is less than or equal
+          to that of the largest signed integer type supported by the
+          implementation.
+
+        - For a modular integer subtype, the Alignment is less than or equal
+          to that of the largest modular type supported by the implementation.
+
+        - For an enumerated subtype, the Alignment is less than or
+          equal to that of the largest signed integer type, or the largest
+          modular type, which ever is least aligned.
+
+        - For fixed point, floating point, access, protected and task subtypes:
+          the Alignment is what would have been chosen by default.
+
 Implementation Advice:
 
     If a type obeys the rules for well-defined unchecked conversion
@@ -40,7 +59,7 @@
     clause that is the same as what the implementation would have chosen
     by default.
 
-!question 96-09-15
+!question
 
 The wording of 13.2(7-9) seems vague.  For example, it refers to "packed
 as tightly as possible".  What does this imply about the Size of a
@@ -52,14 +71,16 @@
 is the minimum needed, based on the range.  Which is correct?  (The
 former.)
 
-!recommendation 96-04-11
+!recommendation
 
 (See summary.)
 
-!wording 96-04-11
+!wording
 
-!discussion 98-03-27
+To Be Determined.
 
+!discussion
+
 In the following examples, assume that the word size is 32 bits.
 
 13.2(7-9) says:
@@ -217,9 +238,54 @@
 matches T, because T'Base is unconstrained, whereas T is constrained.
 Therefore, we do not specify that T'Base is 32 here.  The base range is
 not a constraint.
+
+The RM defines the recommended level of support as follows:
+
+13.3 says:
+
+29   The recommended level of support for the Alignment attribute for
+subtypes is:
 
-!appendix 96-06-06
+   30  An implementation should support specified Alignments that are
+       factors and multiples of the number of storage elements per word,
+       subject to the following:
+
+   31  An implementation need not support specified Alignments for
+       combinations of Sizes and Alignments that cannot be easily loaded
+       and stored by available machine instructions.
+
+   32  An implementation need not support specified Alignments that are
+       greater than the maximum Alignment the implementation ever
+       returns by default.
+
+These recommendations are hard requirements for implementations that
+support the Systems Programming Annex, by C.2(2):
+
+ 2
+ The implementation shall support at least the functionality defined by the
+ recommended levels of support in Section 13.
+
+These requirements are both vague, and possibly require implementations to
+support non-natural alignments. Therefore, we replace paragraph 31 by specific
+advice.
+
+It seems unreasonable to require arbitrary values (even within the restricted
+set defined above) for discrete types. Values already supported for the class
+make sense, since the implementation already knows how to do such alignments.
+But other alignments could have implementation problems, and don't add any
+real functionality. There may be hardware requirements on the alignment of
+fixed point, floating point, and access types, so we place no requirements
+other than to support "confirming" Alignment clauses. There is no compelling
+reason to require any alignments on task and protected types, so we place
+no requirements on them. For arrays, any alignment supported for the component
+subtype should be supported for the entire array, but no more. For records,
+Tucker thinks some reasonable implementations require alignments and sizes
+to be related, so we adopt a rule to make those implementations possible.
+(Many of us would like more justification for this rule, but Alignments of
+subtypes aren't important enough to worry about it).
 
+!appendix
+
 !section 13.3(55)
 !subject Missing AI: When is the Size "specified" for a subtype?
 !reference RM95-13.3(55)
@@ -227,11 +293,11 @@
 !reference 95-5373.b Tucker Taft 95-10-30>>
 !discussion
 
-In 13.3(55), it defines a recommended meaning for Size, when it is 
-not "specified" for a subtype.  Throughout the language, two 
+In 13.3(55), it defines a recommended meaning for Size, when it is
+not "specified" for a subtype.  Throughout the language, two
 statically matching subtypes are considered completely equivalent. Hence,
-if a subtype statically matches the first subtype, and the size 
-has been specified for the first subtype, then Size should be 
+if a subtype statically matches the first subtype, and the size
+has been specified for the first subtype, then Size should be
 considered "specified" for the statically matching subtype.
 Or to put it another way, all statically matching subtypes should
 have the same value for 'Size.
@@ -240,11 +306,11 @@
 13.3(55) would create numerous problems.  In particular, if
 one said that specifying a size for a first subtype "broke"
 static matching between the first subtype and other subtypes whose
-constraints statically match those of the first subtype, then putting 
-on a "confirming" rep-clause could seriously alter the correctness 
-of a program.  Alternatively, if one said that only specifying a 
-non-confirming rep-clause would "break" static matching, then compilers 
-that differed over what was the default Size for a subtype could have 
+constraints statically match those of the first subtype, then putting
+on a "confirming" rep-clause could seriously alter the correctness
+of a program.  Alternatively, if one said that only specifying a
+non-confirming rep-clause would "break" static matching, then compilers
+that differed over what was the default Size for a subtype could have
 dramatically different effects with respect to static subtype matching.
 (Remember that compilers that do not support the S.P. Annex need
 not obey 13.3(55).)
@@ -258,9 +324,9 @@
     Note that there has been some interest in reviving the ability
     to specify sizes on "secondary" subtypes.  The above suggested
     interpretation for "specified" should not be interpreted to
-    affect this possibility either way.  If a secondary subtype 
+    affect this possibility either way.  If a secondary subtype
     were to have a Size specified, then we would have to determine
-    how such rep-clauses would interact with static matching.  
+    how such rep-clauses would interact with static matching.
     However, even if such rep-clauses were allowed, we believe that
     when they are *not* present, any subtypes which statically
     match the first subtype must have the same 'Size as the first
@@ -376,7 +442,7 @@
     implicitly specifying the size for any statically matching
     subtypes (because of the requirement of 13.1(14), and that
     therefore the default ("if not specified") size rule does not
-    apply. 
+    apply.
 
     Using TA, in the above example, with the size clause, the
     value of Number_Of_Hotels'Size would become 16.
@@ -408,7 +474,7 @@
    subtype without modifying the behavior in any way. This is important,
    since apparently one of Tuck's main concerns is that confirming rep
    clauses not have any semantic effect.
- 
+
    (I agree that confirming rep clauses should not have any effect, but in
    the case of Size, this principle is so badly compromised by the inability
    to give any rep clauses for subtypes at all, not even confirming rep
@@ -507,7 +573,7 @@
 
 Because of these static matching rules. The attempt was to ensure that
 13.1(14) is in fact true, and that specifying sizes for subtypes could
-not disrupt it. 
+not disrupt it.
 
 But that did not get done cleanly as we see.
 
@@ -668,22 +734,22 @@
 led me to observe that the following:
     package Rec_IO is new Direct_IO (Rec);
 would cause real problems when a database is maintained using
-Rec_IO bt different invocations of the program, with different 
+Rec_IO bt different invocations of the program, with different
 values of N.    The expectation (guaranteed by Ada83 because Y
 is a subtype and not a type, I beleive), is that objects of
 type Rec are the same size.  This is a particular issue for
-Direct_IO, where the data layouts can depend very strongly on 
-the size of the object.  
+Direct_IO, where the data layouts can depend very strongly on
+the size of the object.
 
 Ada95 clearly violates its "no surprises" guideline by having
 the size of a subtype change in this way.  I find it basically
-counterintuitive (and unacceptable) to have to do a lot of 
+counterintuitive (and unacceptable) to have to do a lot of
 representation clauses for an 'invariant' that should be machine
 independent, i.e. that objects of the type Rec are the same
 size, regardless of the value of the constraint N.  In particular,
 if this causes Direct_IO to fail because of varying values of N,
 then we lose type 'equivalence', exchanging it for subtype
-equivalence.  (What I mean here is that 2 values of the same type 
+equivalence.  (What I mean here is that 2 values of the same type
 can be used, subject only to subtype constraint checks.)
 
                 dave
@@ -706,13 +772,13 @@
 clarification?
 
 > (This comment is being submitted on behalf of Robert Dewar.)
-> 
+>
 > Some comments on the SIZE problem and Issue
 > -------------------------------------------
-> 
+>
 > First of all, let's look at the current rules in the absence of size
 > clauses:
-> 
+>
 >    type Count is Integer range 1 .. 65;
 
 That's not legal syntax.  You must mean one of these:
@@ -739,38 +805,38 @@
 >    type Count_Ptr     is access all Count;
 >    type Companies_Ptr is access all Number_Of_Companies;
 >    type Hotels_Ptr    is access all Number_Of_Hotels
-> 
+>
 > We have, according to paragraph 13.3(55):
-> 
+>
 >    Count'Size = 7
 >    Number_Of_Companies'Size = 6;
 >    Number_Of_Hotels'Size = 7;
-> 
+>
 > This is required. In Ada 83, many (most? nearly all?) compilers would
 > have given Integer'Size to all three types, but Ada 95 requires that
 > the sizes be minimal. This causes a number of subtle incompatibilities
 > but we already (unwisely in my view, I will not hide this) decided to
 > introduce this behavior.
-> 
+>
 > Moreover, type Count_Ptr is convertible to type Hotels_Ptr, but
 > not to type Companies_Ptr.
-> 
+>
 > This again seems very strange, but that's the way the language is,
 > and for this to work, we need to worry about:
-> 
+>
 >    X : aliased Count_Ptr;
 >    Y : aliased Hotels_Ptr;
-> 
+>
 > where X'Access and Y'Access must be interconvertible. This means that
 > X and Y must be stored using the same representation.
-> 
+>
 > In the absence of Size clauses, Ada 95 achieves this requirement by
 > the default size rules in 13.3(55), and in this case 13.1(14) clearly
 > is correct:
-> 
+>
 >   "If two subtypes statically match, then their subtype-specific
 >    aspects (Size and Alignment) are the same"
-> 
+>
 > Together with the assumption (perhaps it is a requirement, but I
 > can't see the reference right now and anyway it is not really
 > relevant to this argument which it is) that the two objects will
@@ -783,41 +849,41 @@
 
 > What Happens When we Add Size Clauses
 > -------------------------------------
-> 
+>
 > 13.3(55) allows a size to be specified for the first subtype. If this
 > is a confirming size, then all is well, but consider in the above
 > example what happens when we write:
-> 
+>
 >    type Count is Integer range 1 .. 65;
 
 Same bug as above.
 
 >    subtype Number_Of_Companies is Count range 1 .. 64;
 >    subtype Number_Of_Hotels    is Count range 1 .. 65;
-> 
+>
 >    for Count'Size use 16;
-> 
+>
 >    type Count_Ptr     is access all Count;
 >    type Companies_Ptr is access all Number_Of_Companies;
 >    type Hotels_Ptr    is access all Number_Of_Hotels
-> 
+>
 > A straightforward reading of 13.3(55) would clearly suggest that the
 > size clause affects only the size of Count, and that we would have:
-> 
+>
 >    Count'Size = 16;
 >    Number_Of_Companies'Size = 6;
 >    Number_Of_Hotels'Size = 7;
-> 
+>
 > But now we are in trouble, the subtypes Count and Number_Of_Hotels
 > still appear to staticaly match, but 13.1(14) is violated. So
 > something is wrong.
-> 
+>
 > There are two basic approaches one can take to solving this problem:
-> 
+>
 >   Tuck's Approach
-> 
+>
 >     Hereinafter referred to as TA
-> 
+>
 >     TA reads 13.1(14) as a requirement rather than an observation,
 >     even though it does not have a shall in it. So the effect of 13.1(14)
 >     in TA is that if the other rules on static subtypes are met, then
@@ -837,22 +903,22 @@
 >     implicitly specifying the size for any statically matching
 >     subtypes (because of the requirement of 13.1(14), and that
 >     therefore the default ("if not specified") size rule does not
->     apply. 
-> 
+>     apply.
+>
 >     Using TA, in the above example, with the size clause, the
 >     value of Number_Of_Hotels'Size would become 16.
-> 
+>
 >   Dewar's approach
-> 
+>
 >     Hereinafter referred to as DA
-> 
+>
 >     Does not treat 13.1(14) as a requirement, but rather a statement
 >     about what is true about static subtypes. In other words, if this
 >     is not true, then the subtypes do not statically match. Roughly
 >     the view is that if you state a rule such as:
-> 
+>
 >       "Identical twins always have the same sex"
-> 
+>
 >     and then you look at a boy and a girl, you know they are not identical
 >     twins, no matter what rules have been stated elsewhere.
 
@@ -867,28 +933,28 @@
 
 >     DA then takes the more natural reading of 13.3(55), and assumes that
 >     the size clause applies only to the first named subtype.
-> 
+>
 >   Tuck mentions a third approach as a strawman in his comments on this
 >   subject, but (a) I don't understand it, and (b) as far as I can tell
 >   no one is arguing for it, so I won't bother with it.
-> 
+>
 > Now, some comments on the two approaches:
-> 
+>
 > 1. Both TA and DA allow confirming rep clauses to be added for the first
 >    subtype without modifying the behavior in any way. This is important,
 >    since apparently one of Tuck's main concerns is that confirming rep
 >    clauses not have any semantic effect.
->  
+>
 >    (I agree that confirming rep clauses should not have any effect, but in
 >    the case of Size, this principle is so badly compromised by the inability
 >    to give any rep clauses for subtypes at all, not even confirming rep
 >    clauses, that I can't get too excited about it, but in any case, DA
 >    allows confirming rep clauses that are neutral).
-> 
+>
 > 2. DA means that a non-confirming size clause can affect the convertability
 >    of pointers to different subtypes. This is presumably the overwhelming
 >    concern that leads to the preference of TA.
-> 
+>
 >    However, I must say I am underwhelmed. First of all it is a bit bizarre
 >    that the legality of these conversions depends on the equality of values
 >    that are likely to be logically related in the program (for example in
@@ -906,22 +972,22 @@
 not happen.
 
 >    Furthermore, it seems quite natural to me that if you have two types:
-> 
+>
 >       access X
 >       access Y
-> 
+>
 >    that they are convertible only if the representations of X and Y are
 >    the same, and if you specifically modify the representation of X and
 >    do not modify the representation of Y, then they are no longer
 >    convertible.
-> 
+>
 > 3. TA means that a size clause affects the size of a previously declared
 >    subtype. This seems peculiar, and I can see it causing implementation
 >    problems. For non subtype specific attributes, there is no problem,
 >    since the representation is an attribute of the base type.
-> 
+>
 >    DA does not at all like this retrospective effect.
-> 
+>
 >    TA does not care much, since one pass semantics aren't considered too
 >    important, and anyway that's not quite fair, because you can think of
 >    sizes as only being established at the freeze point.
@@ -937,34 +1003,34 @@
 >    which happen to statically match, and that saying that this is the case
 >    will complicate 13.3(55). For example, TA could be made clear by adding
 >    to this paragraph the following sentence:
-> 
+>
 >      Such a specification affects the first named subtype, and any other
 >      subtypes of the same base type that statically match.
-> 
+>
 >    Probably a note needs to be added:
-> 
+>
 >      This affects both subtypes declared previously to the size clause,
 >      and any subsequent subtypes declared in either the same declarative
 >      region or elsewhere.
-> 
+>
 >    because this is quite surprising (that the size of a subtype in another
 >    unit would be affected). The actual processing for subtypes in other
 >    units is now something like:
-> 
+>
 >      If the subtype statically matches the first named subtype, then take
 >      the size of the first named subtype, otherwise take the default size
 >      from paragraph 13.3(55).
-> 
+>
 >    By contrast, the effect of DA on the RM would be as follows:
-> 
+>
 >      Remove 13.1(14) completely
-> 
+>
 >      Add to the first sentence of 4.9.1(2), giving
-> 
+>
 >      "A subtype statically matches another subtype of the same type if they
 >       have statically matching constraints, and if they have the same
 >       subtype specific aspects (Size and Alignment)".
-> 
+>
 > What we have here is two conflicting requirements in the RM. I think in such
 > cases it is a waste of time to make arguments saying essentially that you
 > can conclude that one is wrong by intent because it must be wrong, given
@@ -972,24 +1038,24 @@
 > is unhelpful. I mention this, because TA uses this argument, arguing that
 > 13.1(14) implies the desired constructive reading of 13.3(55). DA could
 > make the same argument the other way round, but it is besides the point.
-> 
+>
 > What we need is a resolution that is least suprising, and simplest.
-> 
+>
 > Ulterior Motive Disclosed
 > -------------------------
-> 
+>
 > DA will now disclose an ulterior motive.
-> 
+>
 > Up until the last moment, Ada 95 allowed 'Size to be specified for subtypes.
 > GNAT implemented this capability, and it was definitely useful. It was
 > removed from the RM late on without WG9 discussion.
-> 
+>
 > Why?
-> 
+>
 > Because of these static matching rules. The attempt was to ensure that
 > 13.1(14) is in fact true, and that specifying sizes for subtypes could
-> not disrupt it. 
-> 
+> not disrupt it.
+>
 > But that did not get done cleanly as we see.
 
 This history is correct.
@@ -997,19 +1063,19 @@
 > To me, the removal of a really useful feature, just so that the very
 > marginal feature of being able to convert pointers to logically unrelated
 > subtypes would work, is a very poor trade off.
-> 
+>
 > It is particularly important to be able to specify the size of subtypes
 > given the (in my view injudicious) introduction of the rules in Ada 95
 > that require separate sizes for subtypes (Ada 83 allowed it but did not
 > require it, few compilers took advantage of it, the only one I know of
 > that did systematically what is now required is the old Intermetrics
 > compiler).
-> 
+>
 > This means that if we have
-> 
+>
 >    type X is range 0 .. 65535;
 >    for X'Size use 16;
-> 
+>
 >    subtype Y is X range 1 .. N;
 >    -- N is a constant that happens today to be 255
 
@@ -1017,22 +1083,22 @@
 assumed N is non-static, which I think confuses the issue.
 
 >    then Y'Size is 8, and that in the record:
-> 
+>
 >       type Rec is record
 >          XV : X;
 >          YV : Y;
 >       end record;
-> 
+>
 >    XV is likely to occupy 16 bits, and YV to occupy 8 bits. This could well
 >    be incompatible with existing programs, and note that it would require
 >    most vendors to change their size rules, and behavior of their systems
 >    (with the sole exception of the Intermetrics compiler, which is indeed
 >    compatible with the old Intermetrics compiler).
-> 
+>
 > This was not *too* worrisome before the last minute change, since at least
 > you could use a size clause (in this case "for Y'size use X'Size) that
 > would override the default, and duplicate old behavior.
-> 
+>
 > Furthermore, the introduction of the restriction means that it is not
 > possible to specify confirming size clauses. So you have a situation in
 > which compared to Ada 83, the sizes of subtypes are required to vary in
@@ -1048,14 +1114,14 @@
 > DA has the very interesting property that if it is adopted, then there is
 > no reason not to allow compilers to specify the size of subtypes, undoing
 > the ill effects of the last minute, incompletely executed, change.
-> 
+>
 > A comment here is that MANY readers of Ada 95 assume that subtype specific
 > attributes can be specified for subtypes. That seems a reasonable assumption
 > and used to be a correct one, but is now surprisingly false. We have got a
 > number of bug reports from people complaining that GNAT does not allow such
 > specifications. We can of course explain that GNAT is right, but the
 > principle of least suprise is definitely violated!
-> 
+>
 > Incidentally, a major use for specifying subtype sizes is in building
 > packed records. You just specify the size of each subtype, and then say
 > pragma Pack, and everything packs together nicely without needing to
@@ -1064,14 +1130,14 @@
 > You don't want to specify the exact layout, but you do want to control
 > the nature of the packing. Yes there are other ways to do this, e.g.
 > by using derived types, but they are messy by comparison.
-> 
+>
 > The other major reason for specifying subtype sizes is in porting legacy
 > code, where you want to confirm size choices made by a previous Ada 83
 > compiler.
-> 
+>
 > These requirements are strong enough that in GNAT we definitely intend to
 > implement a feature for this purpose.
-> 
+>
 > If TA is adopted, GNAT will introduce an attribute Subtype_Size that can
 > be applied to arbitrary subtypes, and which will compromise static matching
 > in some cases. This attribute is probably technically an extension because
@@ -1090,7 +1156,7 @@
 
 > A note for Bob Duff
 > -------------------
-> 
+>
 > Yes, yes, all this applies to Alignment too. I can't get excited about
 > alignments for subtypes. At least there is no analog to 13.3(55) requiring
 > an injudicious choice of default alignments.
@@ -1103,9 +1169,9 @@
 
 > To be Honest
 > ------------
-> 
+>
 > There are a couple more glitches here
-> 
+>
 > First, with respect to dynamic subtypes. We have to worry about dynamic
 > subtypes, since they can statically match. For dynamic subtypes, if you
 > want to be sure that access types to them are inter-convertible, then
@@ -1140,14 +1206,14 @@
 
 > Original Intent
 > ---------------
-> 
+>
 > Arguments from original intent are somewhat bogus, since the RM does not
 > contain its history.
-> 
+>
 > One could say that the longer term intent was that Size should be able
 > to be specified for subtypes, and that the language "subtype specific"
 > still implies this -- a bogus argument for DA.
-> 
+>
 > One could also say that the removal of this capability obviously means
 > that 13.1(14) was considered sacrosanct -- a bogus argument for TA.
 
@@ -1164,7 +1230,7 @@
 
 > Conclusion
 > ----------
-> 
+>
 > There is a real disagreement here. Needs discussion!
 
 Indeed.
@@ -1274,9 +1340,9 @@
             Z: One_Bit_Int;
         end record;
     pragma Pack(Inner_Record);
-    
+
     type Twenty_Nine_Bits is range 0..2**29-1; -- Twenty_Nine_Bits'Size = 29.
-    
+
     type Outer_Record is
         record
             Inner: Inner_Record;
@@ -1356,21 +1422,21 @@
 > clause" should not change things.  That is, if you have a program where
 > T'Size = 32 by default, and you add a rep clause, "for T'Size use 32;",
 > then the semantics of the new program should be identical.
-> 
+>
 > For most rep clauses, in most situations, we have achieved this
 > principle.  However, there are some cases where the principle is
 > compromised.  In particular 13.3(50-52) says:
-> 
+>
 >   50   If the Size of a 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:
-> 
+>
 >      51  Aliased objects (including components).
-> 
+>
 >      52  Unaliased components, unless the Size of the component is
 >          determined by a component_clause or Component_Size clause.
-> 
+>
 > The phrase "If the Size of a subtype is specified" clearly violates the
 > principle that confirming rep clauses shouldn't change things.  The
 > principle is still a good principle -- we probably ought to at least try
@@ -1515,7 +1581,7 @@
 
 (which are possibly conflicting)
 
-o  it should be possible to write confirming rep clauses for all 
+o  it should be possible to write confirming rep clauses for all
         representation choices made by the compiler
 
 o  the sizes chosen by an Ada 95 compiler should match those of an Ada 83
@@ -1575,10 +1641,10 @@
 
   type x is (a,b,c);
 
-in Verdix x'size is 8 or somesuch, BUT Verdix allowed pragma Pack to 
+in Verdix x'size is 8 or somesuch, BUT Verdix allowed pragma Pack to
 go ahead and pack to 2 bits anyway. This is inconsistent with the Paris
 meeting AI's and with the RM, but in practice, the packing is more
-important than the size, so the RM rules are most practical. 
+important than the size, so the RM rules are most practical.
 
 
 ****************************************************************
@@ -1593,11 +1659,11 @@
 !discussion
 
 > let me narrow down my size comments to a set of requirements
-> 
-> 
+>
+>
 > (which are possibly conflicting)
-> 
-> o  it should be possible to write confirming rep clauses for all 
+>
+> o  it should be possible to write confirming rep clauses for all
 >       representation choices made by the compiler
 
 Good principle, usually, but we know we've violated it in *some* cases.
@@ -1622,18 +1688,18 @@
 
 > o  the sizes chosen by an Ada 95 compiler should match those of an Ada 83
 >       compiler
-> 
+>
 > o  (most important). If the second rule is not met, it should be possible
 >       to write rep clauses that cuase the choice to match that of the
 >       Ada 83 compiler.
-> 
+>
 > I never liked what was going on with size in RM 95 as you now, but did not
 > mind too much as long as 'size could be specified for a subtype as was
 > the case till very late on.
-> 
+>
 > It is taking that away that has left RM 95 completely broken with respect
 > to the critical third requirement above.
-> 
+>
 > It is merely annoying that the size rules are peculiar, and reflect not
 > the best approximation of industry pratice in Ada 83, but rathr the
 > behavior of one particular vendors compiler that was in fact not a
@@ -1689,9 +1755,9 @@
 
 > Ada 95 broke that (why I don't know), but I could live with it because
 > I could specify size for a subtype.
-> 
+>
 > At this stage I would like to see:
-> 
+>
 >   o  THat compilers be allowed to specify 'size for other than first
 >      subtypes, but not required to do so.
 
@@ -1713,12 +1779,12 @@
 > I don't care too much if you keep the bizarre rule about sizes happening
 > to be different if the subtype happens to statically match the first subtype,
 > as long as I can override it.
-> 
+>
 > In fact I don't too much care WHAT is done, since it is only a matter of
 > aesthetics, not functionality. If the ARG does not solve this question,
 > e.g. in the manner suggested above, then GNAT will simply implement
 > 'Subtype_Size and solve the problem itself.
-> 
+>
 > This is not a theoretical issue, we are currently not following the RM
 > rules, because we know they will break customer code in a manner that
 > is not easy to provide work arounds for (note in particular that there
@@ -1728,13 +1794,13 @@
 
 > P.S. I would in fact be inclined to keep the current RM rules about
 > minimum size, consider the following:
-> 
+>
 >   type x is (a,b,c);
-> 
-> in Verdix x'size is 8 or somesuch, BUT Verdix allowed pragma Pack to 
+>
+> in Verdix x'size is 8 or somesuch, BUT Verdix allowed pragma Pack to
 > go ahead and pack to 2 bits anyway. This is inconsistent with the Paris
 > meeting AI's and with the RM, but in practice, the packing is more
-> important than the size, so the RM rules are most practical. 
+> important than the size, so the RM rules are most practical.
 
 OK, good, we agree on *some* things.  ;-)
 
@@ -1765,7 +1831,7 @@
 And I replied:
 
 > Unfortunately, Ada 95 allows:
-> 
+>
 >     type T is range 0..1;
 >     for T'Size use 1;
 >     subtype S is range -1..1;
@@ -1775,10 +1841,10 @@
 wider range than the first subtype, so:
 
 > Clearly, we cannot require that S'Size be 1.
-> 
+>
 > I suppose we could require it for subtypes whose range happens to be
 > small enough.
-> 
+>
 > No, that won't work, either, because the range might not be known at
 > compile time.  I guess the rule would have to say something about
 > staticness.  Or, we could make it all implementation-defined, and let
@@ -3020,7 +3086,7 @@
 
   - For fixed point, up to the Size of the largest fixed point
     type supported by the implementation.
- 
+
   - For floating point, up to the Size of the largest floating point
     type supported by the implementation.
 
@@ -3135,7 +3201,7 @@
 >the internal representation. The idea of having Size affect the precision
 >is not at all in the spirit of the RM requirements, and would be actively
 >undesirable (though not non-conformant, just undesirable). I think it would
->be helpful if the AI makes clear that this is undesirable and explains why. 
+>be helpful if the AI makes clear that this is undesirable and explains why.
 
 Well, I completely disagree about the 'undesirable' part.
 
@@ -3261,7 +3327,7 @@
 !reference AI95-00051
 !reference AI95-00109
 !reference 96-5552.a Ken Garlington  96-5-13
-!keywords Size 
+!keywords Size
 !reference 96-5564.a Robert Dewar 96-5-18
 !reference 96-5570.a Robert Dewar 96-5-22
 !from Randy Brukardt
@@ -3338,8 +3404,8 @@
 record component clauses].  Unfortunately, such a change
 is too much for the ARG to undertake.)
 
+
 
- 
 
 
 
@@ -3404,7 +3470,7 @@
 !reference AI95-00051
 !reference AI95-00109
 !reference 96-5552.a Ken Garlington  96-5-13
-!keywords Size 
+!keywords Size
 !reference 96-5564.a Robert Dewar 96-5-18
 !reference 96-5570.a Robert Dewar 96-5-22
 !reference 96-5571.a Ian Goldberg  96-5-23

Questions? Ask the ACAA Technical Agent