CVS difference for ai05s/ai05-0092-1.txt

--- ai05s/ai05-0092-1.txt	2009/11/24 06:09:12	1.9
+++ ai05s/ai05-0092-1.txt	2010/04/05 23:34:15	1.10
@@ -1,4 +1,5 @@
-!standard  3.3.1(20.4/2)                                09-11-23  AI05-0092-1/08
+!standard  3.3.1(20.4/2)                             10-04-05  AI05-0092-1/09
+!standard  3.3.1(23)
 !standard  3.9(25.1/2)
 !standard  6.3.1(21.1/2)
 !standard  9.6(22)
@@ -57,6 +58,8 @@
 
 13) Correct the note D.5.1(18).
 
+14) Correct the note 3.3.1(23).
+
 !question
 
 1) Generally, "must" shall not be used in normative rules of the standard. However,
@@ -95,6 +98,11 @@
 13) The Note D.5.1(18) talks about when Tasking_Error is raised by Set_Priority. But
 Tasking_Error is never raised by Set_Priority, so this note is confusing.
 
+14) The Note 3.3.1(23) says that a formal_object_declaration
+"is not called a stand-alone object", while 12.4(10/2) says that a
+formal_object_declaration of mode in is "a stand-alone constant object"
+within an instance. This note must be wrong, should it be fixed? (Yes.)
+
 [Other questions here.]
 
 !recommendation
@@ -138,6 +146,13 @@
 allowed, so long as the task is not yet terminated{, and setting the priority of a task
 is allowed for any task state (including for terminated tasks)}.
 
+14) Modify the Note 3.3.1(23):
+
+An object declared by a loop_parameter_specification, parameter_specification,
+entry_index_specification, choice_parameter_specification,
+{extended_return_statement,} or a formal_object_declaration {of mode IN OUT} is
+not [called] {considered} a stand-alone object.
+
 !discussion
 
 1) 3.3.1(20.4/2) uses "must precede", while 3.3.1(20.1-3/2) use "is preceded by".
@@ -184,6 +199,11 @@
 13) The note is technically correct, but it is misleading. The rewrite makes it
 clearer that Set_Priority is always allowed.
 
+14) We don't like notes that lie, so we correct it to match the normative
+semantics. (We have no reason to assume that the normative semantics are wrong.)
+We also mention extended return objects in this list, since they are a similar
+kind of object that is not considered stand-alone.
+
 !corrigendum 3.3.1(20.4/2)
 
 @drepl
@@ -201,6 +221,28 @@
 earlier in the order of the component declarations precede the initial
 value evaluations of the component occurring later.>
 
+!corrigendum 3.3.1(23)
+
+@drepl
+@xindent<@s9<8 As indicated above, a stand-alone object is an object declared
+by an @fa<object_declaration>. Similar definitions apply to "stand-alone
+constant" and "stand-alone variable." A subcomponent of an object is not a
+stand-alone object, nor is an object that is created by an @fa<allocator>. An
+object declared by a @fa<loop_parameter_specification>,
+@fa<parameter_specification>, @fa<entry_index_specification>,
+@fa<choice_parameter_specification>, or a @fa<formal_object_declaration> is
+not called a stand-alone object.>>
+@dby
+@xindent<@s9<8 As indicated above, a stand-alone object is an object declared
+by an @fa<object_declaration>. Similar definitions apply to "stand-alone
+constant" and "stand-alone variable." A subcomponent of an object is not a
+stand-alone object, nor is an object that is created by an @fa<allocator>. An
+object declared by a @fa<loop_parameter_specification>,
+@fa<parameter_specification>, @fa<entry_index_specification>,
+@fa<choice_parameter_specification>, @fa<extended_return_statement>, or
+a @fa<formal_object_declaration> of mode @b<in out> is
+not considered a stand-alone object.>>
+
 !corrigendum 3.9(25.1/2)
 
 @drepl
@@ -501,7 +543,7 @@
 
 I get 22 occurrences, by the way:
 
-@ grep -i must rm.txt 
+@ grep -i must rm.txt
 parts: a specification, containing the information that must be visible to
 must name the library units it requires.
 specifies a Boolean expression (an entry barrier) that must be True before the
@@ -528,7 +570,7 @@
      22     224    1637
 @ grep -i must aarm.txt |wc
     122    1271    8910
-@ 
+@
 
 I'll bet most of these come from Ada 83 or Ada 95 wording.
 
@@ -676,7 +718,7 @@
 In the correct order.)
 
 > > I'll bet most of these come from Ada 83 or Ada 95 wording.
-> 
+>
 > How much? The winnings would help ease my embarrassment about this issue!
 
 My standard amount in these cases is a nickel.  I didn't search the older
@@ -746,7 +788,7 @@
     Bounded is replaced by Wide_Wide_Bounded.
 
 The names noted are incorrect: they should be Bounded_Wide_String and
-Bounded_Wide_Wide_String. 
+Bounded_Wide_Wide_String.
 
 There are similar errors in A.11(5).
 
@@ -824,3 +866,180 @@
 [This is item #3 above. - Editor]
 
 ****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 15, 2010  4:54 PM
+
+I was trying to answer a question about "stand-alone objects", and noticed that
+the Note 3.3.1(23) says that a formal_object_declaration "is not called a
+stand-alone object", while 12.4(10/2) says that a formal_object_declaration of
+mode in is "a stand-alone constant object" within an instance.
+
+One of these must be wrong! We generally have a rule that Notes shouldn't lie,
+so I think it needs to be adjusted somehow. (It's interesting that this has been
+true since the original Ada 95 standard, and no one has complained before).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, March 15, 2010  5:06 PM
+
+Good catch.
+
+The note should probably be reworded without the use of the term "called."
+E.g.:
+
+   An object declared by a loop_parameter_specification,
+   parameter_specification, entry_index_specification,
+   choice_parameter_specification, or a
+   formal_object_declaration {of mode IN OUT} is not [called]
+   {considered} a stand-alone object.
+
+[This is item #14 above - Editor.]
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, March 15, 2010  5:11 PM
+
+...
+> One of these must be wrong! We generally have a rule that Notes
+> shouldn't lie, so I think it needs to be adjusted somehow. (It's
+> interesting that this has been true since the original Ada 95
+> standard, and no one has complained before).
+
+Are you sure we want to fix this bug, at the risk of putting in new bugs?
+
+To do it right, we'd need to search for all occurrences of "stand-alone".
+There are 90 of them.  I'm not inclined to do that work, unless some compiler
+writer is likely to do the wrong thing because of this.
+
+The first one is in RM-3.3:
+
+23.5/3   * it is part of a stand-alone constant (including a generic formal
+      object of mode in); or
+
+which agrees with 12.4(10/2).
+
+I invented the term "stand-alone object", but now I'm puzzled by it.
+I would have thought it means an object that is not allocated by "new", and not
+a component of some other object.  And maybe not a parameter (which is
+more-or-less view-like).
+
+That is, something that should be stack-allocated, as a whole.
+(Viewing static allocation as an optimization of the "stack frame"
+of the env task.  And registers as an optimization of stack-allocated
+stuff.)
+
+So I'm puzzled by the fact that a loop parameter is not "stand-alone", for
+example.
+
+Anyway, I suspect it's the NOTE that is wrong.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 15, 2010  5:37 PM
+
+> Are you sure we want to fix this bug, at the risk of putting in new
+> bugs?
+
+Well, the bug is in a note, so it hardly could be a "new" bug if we change it. I
+surely wouldn't change the normative rules (I doubt very much that they are
+wrong) unless we were sure there was a problem.
+
+> To do it right, we'd need to search for all occurrences of "stand-alone".
+> There are 90 of them.  I'm not inclined to do that work, unless some
+> compiler writer is likely to do the wrong thing because of this.
+
+I already did it; I didn't check them all, but most are in notes of various
+kinds. (These appear in 28 subclauses.)
+
+> The first one is in RM-3.3:
+>
+> 23.5/3   * it is part of a stand-alone constant (including a
+> generic formal
+>       object of mode in); or
+>
+> which agrees with 12.4(10/2).
+
+I didn't discover this one, though, and it worries me that there is a *real*
+bug. Since a loop parameter or extended return object is not a stand-alone
+object, there is definitely room for a hole. But it is because of misuse of the
+existing term "stand-alone" in next text.
+
+> I invented the term "stand-alone object", but now I'm puzzled by it.
+> I would have thought it means an object that is not allocated by
+> "new", and not a component of some other object.  And maybe not a
+> parameter (which is more-or-less view-like).
+>
+> That is, something that should be stack-allocated, as a whole.
+> (Viewing static allocation as an optimization of the "stack frame"
+> of the env task.  And registers as an optimization of stack-allocated
+> stuff.)
+>
+> So I'm puzzled by the fact that a loop parameter is not "stand-alone",
+> for example.
+
+The Ada 95 use of the term "stand-alone" is to specify which objects can have
+representation clauses. We don't want to be able to give address or size clauses
+for loop parameters or subprogram parameters (or extended return objects, for
+that matter). I'm surprised that we would want to allow that for formal
+parameters of mode in, but the wording is clearly intentional.
+
+I hope that most of the rules actually depend on the wording as it is, and not
+using the term as it appears to be. (I unfortunately did that in the AI-144
+wording, which is what prompted Steve's question to me.) I worry a bit that
+there are more such cases (although I didn't find any given a quick
+examination).
+
+[More research on 3.3(23.1-9) shows that whoever wrote that - I think it was
+Steve - did check what "stand-alone" was defined to mean, as there is a separate
+rule for extended return statements. Loop parameters can't be composite (yet,
+anyway), so it doesn't need to be covered there. So there is no problem.]
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, March 15, 2010  6:06 PM
+
+> I didn't discover this one, though, ...
+
+Ahah!  Proof that the plain-ascii-text version is A Good Thing!
+
+>...and it worries me that there is a *real*  bug.
+
+Perhaps, but I think "worries" might be a bit overblown.
+I mean, let's not have any nightmares over this.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 15, 2010  6:19 PM
+
+> > I didn't discover this one, though, ...
+>
+> Ahah!  Proof that the plain-ascii-text version is A Good Thing!
+
+Sorry, Bob, I made a quick scan through the various hits just looking at the
+summaries of where the term appeared. I didn't realize this one was in a
+legality rule, so I didn't explicitly check it. I just went back and checked,
+and the usage itself is reported on the search page. So it was found just fine,
+I just didn't open it (nor about 20 of the other hits, either), just like you
+didn't look at the other 89 hits you found.
+
+> >...and it worries me that there is a *real*  bug.
+>
+> Perhaps, but I think "worries" might be a bit overblown.
+> I mean, let's not have any nightmares over this.
+
+At the end of my message, I went back and analyzed this particular wording and
+found no problem. My concern is more general -- I've made the mistake of not
+realizing that some "obvious" cases aren't covered by the term "stand-alone" --
+I just wonder if we made that previously as well. Probably not worth worrying
+about, though, Adam will find it for us.
+
+I'll put the note fix that Tucker suggested into the presentation AI.
+
+****************************************************************
+