!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) !standard 13.3(75/1) !standard 13.13.2(55/2) !standard 13.13.2(56/2) !standard A.11(4/2) !standard A.11(5/2) !standard A.16(68/2) !standard A.18.10(2/2) !standard A.18.11(2/2) !standard A.18.12(2/2) !standard A.18.13(2/2) !standard A.18.14(2/2) !standard A.18.15(2/2) !standard D.5.1(18) !standard G.2.2(11) !class presentation 08-03-05 !status work item 06-03-05 !status received 06-02-13 !priority Low !difficulty Easy !qualifier Omission !subject More presentation issues in the Standard !summary This AI corrects minor errors in the Standard. 1) Drop "must" from 3.3.1(20.4/2) (two places). 2) Replace "must be" with "is" in 6.3.1(21.1/2). 3) Replace "must include" with "includes" in 13.3(8.1/2). 4) Replace "must" by "shall" in 13.13.2(55-56/2). 5) Replace "Safe_last" by "Safe_Last" in G.2.2(11). 6) Drop the "3.9.2" reference from 13.3(75/1). 7) In A.11(4-5/2), replace "Wide_Bounded_String" with "Bounded_Wide_String" and "Wide_Wide_Bounded_String" with "Bounded_Wide_Wide_String". 8) Replace "Interface_Ancestor_Tag" with "Interface_Ancestor_Tags" in 3.9(25.1/2). 9) The routines Wide_Expanded_Name and Wide_Wide_Expanded_Name should be listed in 3.9(25.1/2). 10) Replace "_statement" with "statement". 11) Add a default of "" to the Form parameter. 12) The existing indefinite container forms have differences in contents and in semantics. 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, 3.3.1(20.4/2) uses "must precede" twice. Should this be fixed? (Yes.) 2) "Must" also occurs in 6.3.1(8.1/2). Fix that, too? (Yes.) 3) "Must" also occurs in 13.3(8.1/2). Should that also be fixed? (Yes.) 4) "Must" also occurs in 13.13.2(55-56/2). Sigh. More text to fix? (Yes.) 5) "Safe_last" should be written as "Safe_Last" in G.2.2(11). Fix it? (Yes.) 6) 13.3(75/1) says "See 3.9.2 and 13.13.2". There doesn't appear to be anything relevant in 3.9.2. What is the intent? (Delete it.) 7) A.11(4-5/2) use the wrong names for the Wide and Wide_Wide versions of bounded strings. Fix these? (Yes.) 8) 3.9(25.1/2) mentions "Interface_Ancestor_Tag", but there is no such thing. Change to "Interface_Ancestor_Tags"? (Yes.) 9) 3.9(25.1/2) mentioned "Expanded_Name", but it doesn't mention "Wide_Expanded_Name" and "Wide_Wide_Expanded_Name". Should it? (Yes.) 10) 9.6(22) includes "_statement"; this fragment is unseemly. Should this be replaced by "statement"? (Yes.) 11) A.16(13/2) includes a default of "" for the Form parameter, but A.16(68/2) does not. Should A.16(68/2) have a default for the Form parameter? (Yes.) 12) A.18.10(2/2) [and the other 5 indefinite container forms] says that the contents of package Indefinite_Vectors differs from the contents of package Vectors, but the semantics is changed in various ways as well. Should the wording reflect this? (Yes.) 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 (See summary.) !wording 1) Drop "must" from 3.3.1(20.4/2); it occurs in two places. 2) Replace "must be" with "is" in 6.3.1(21.1/2). 3) Replace "must include" by "includes" in 13.3(8.1/2). 4) Replace "must" by "shall" in 13.13.2(55-56/2). 5) Replace "Safe_last" by "Safe_Last" in G.2.2(11). 6) Remove "3.9.2 and" from 13.3(75/1). 7) In A.11(4-5/2), replace "Wide_Bounded_String" with "Bounded_Wide_String" and "Wide_Wide_Bounded_String" with "Bounded_Wide_Wide_String". 8) Replace "Interface_Ancestor_Tag" with "Interface_Ancestor_Tags" in 3.9(25.1/2). 9) Replace "or Parent_Tag" with "Parent_Tag, Wide_Expanded_Name, or Wide_Wide_Expanded_Name" in 3.9(25.1/2). 10) Replace "_statement" with "statement" in 9.6(22). 11) Replace "Form : in String);" with "Form : in String := "");" in A.16(68/2). 12) Add "and semantics" after "contents" in A.18.10(2/2), A.18.11(2/2), A.18.12(2/2), A.18.13(2/2), A.18.14(2/2), and A.18.15(2/2). 13) Modify the Note D.5.1(18): 32 The rule for when Tasking_Error is raised for Set_Priority or Get_Priority is different from the rule for when Tasking_Error is raised on an entry call (see 9.5.3). In particular, [setting or ]querying the priority of a completed or an abnormal task is 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". "Must" doesn't add anything here, as this is a rule after all -- following it is not optional and we don't need to re-enforce that. 2) 6.3.1(21.1/2) is a definition, and should use "is", not "shall" (or "must"). 3) 13.3(8.1/2) is also a definition, and "must" is just emphasis. 4) 13.13.2(55/2) is an Implementation Requirement, and must use "shall". 13.13.2(56/2) is an Implementation Permission, so "shall" is optional, but just dropping "must" doesn't make much sense (the emphasis is needed). 5) All other references to Safe_Last use a capital 'L', this one should, too. Note that this error dates all the way back to the original Ada 95 Standard. 6) It's possible the author meant 3.9, but that wouldn't be useful, as 3.9(11) just references 13.3. We surely don't want a circular definition, so we just drop the reference. 7) The names of the types ought be consistent between A.4.7, A.4.8, and A.11. 8) An obvious missing 's'. 9) The Wide and Wide_Wide versions of Expanded_Name surely should raise the same exceptions as the base version. Anything else would be madness. Note that the routines are listed in alphabetical order. 10) This is one of a number of similar fragments in the Ada 95 RM. As they interfere with automated linking and indexing (and look like a mistake), we've been eliminating them when possible. We could have used the entire "delay_statement" here, but that would seem redundant (there are two other occurrences of delay_statement in the paragraph). 11) Clearly the specifications given in A.16(13/2) and A.16(68/2) should match. Since Form parameters generally default to "", we believe that A.16(13/2) is correct and change A.16(68/2) to match. 12) It is obvious that more than just the contents are changed for the indefinite forms. For instance, A.18.10(8/2) is not referring to the contents of the package. It is best if the wording reflects that. 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 @xbullet @dby @xbullet !corrigendum 3.3.1(23) @drepl @xindent<@s9<8 As indicated above, a stand-alone object is an object declared by an @fa. 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. An object declared by a @fa, @fa, @fa, @fa, or a @fa 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. 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. An object declared by a @fa, @fa, @fa, @fa, @fa, or a @fa of mode @b is not considered a stand-alone object.>> !corrigendum 3.9(25.1/2) @drepl Tag_Error is raised by a call of Descendant_Tag, Expanded_Name, External_Tag, Interface_Ancestor_Tag, Is_Descendant_At_Same_Level, or Parent_Tag if any tag passed is No_Tag. @dby Tag_Error is raised by a call of Descendant_Tag, Expanded_Name, External_Tag, Interface_Ancestor_Tags, Is_Descendant_At_Same_Level, Parent_Tag, Wide_Expanded_Name, or Wide_Wide_Expanded_Name if any tag passed is No_Tag. !corrigendum 6.3.1(21.1/2) @drepl @xbullet in one must be the same as the corresponding @fa in the other; and> @dby @xbullet in one is the same as the corresponding @fa in the other; and> !corrigendum 9.6(22) @drepl If an attempt is made to @i the @fa (as part of an @fa or abort — see 9.7.4 and 9.8), the @fa<_statement> is cancelled if the expiration time has not yet passed, thereby completing the @fa. @dby If an attempt is made to @i the @fa (as part of an @fa or abort — see 9.7.4 and 9.8), the statement is cancelled if the expiration time has not yet passed, thereby completing the @fa. !corrigendum 13.3(8.1/2) @drepl A @i is an amount of storage that can be conveniently and efficiently loaded, stored, or operated upon by the hardware. Machine scalars consist of an integral number of storage elements. The set of machine scalars is implementation defined, but must include at least the storage element and the word. Machine scalars are used to interpret component_clauses when the nondefault bit ordering applies. @dby A @i is an amount of storage that can be conveniently and efficiently loaded, stored, or operated upon by the hardware. Machine scalars consist of an integral number of storage elements. The set of machine scalars is implementation defined, but includes at least the storage element and the word. Machine scalars are used to interpret component_clauses when the nondefault bit ordering applies. !corrigendum 13.3(75/1) @drepl @xindent; the expression of such a clause shall be static. The default external tag representation is implementation defined. See 3.9.2 and 13.13.2. The value of External_Tag is never inherited; the default value is always used unless a new value is directly specified for a type.> @dby @xindent; the expression of such a clause shall be static. The default external tag representation is implementation defined. See 13.13.2. The value of External_Tag is never inherited; the default value is always used unless a new value is directly specified for a type.> !corrigendum 13.13.2(55/2) @drepl If Constraint_Error is raised during a call to Read because of failure of one the above checks, the implementation must ensure that the discriminants of the actual parameter of Read are not modified. @dby If Constraint_Error is raised during a call to Read because of failure of one the above checks, the implementation shall ensure that the discriminants of the actual parameter of Read are not modified. !corrigendum 13.13.2(56/2) @drepl The number of calls performed by the predefined implementation of the stream-oriented attributes on the Read and Write operations of the stream type is unspecified. An implementation may take advantage of this permission to perform internal buffering. However, all the calls on the Read and Write operations of the stream type needed to implement an explicit invocation of a stream-oriented attribute must take place before this invocation returns. An explicit invocation is one appearing explicitly in the program text, possibly through a generic instantiation (see 12.3). @dby The number of calls performed by the predefined implementation of the stream-oriented attributes on the Read and Write operations of the stream type is unspecified. An implementation may take advantage of this permission to perform internal buffering. However, all the calls on the Read and Write operations of the stream type needed to implement an explicit invocation of a stream-oriented attribute shall take place before this invocation returns. An explicit invocation is one appearing explicitly in the program text, possibly through a generic instantiation (see 12.3). !corrigendum A.11(4/2) @drepl The specification of package Wide_Text_IO.Wide_Bounded_IO is the same as that for Text_IO.Bounded_IO, except that any occurrence of Bounded_String is replaced by Wide_Bounded_String, and any occurrence of package Bounded is replaced by Wide_Bounded. The specification of package Wide_Wide_Text_IO.Wide_Bounded_IO is the same as that for Text_IO.Bounded_IO, except that any occurrence of Bounded_String is replaced by Wide_Wide_Bounded_String, and any occurrence of package Bounded is replaced by Wide_Wide_Bounded. @dby The specification of package Wide_Text_IO.Wide_Bounded_IO is the same as that for Text_IO.Bounded_IO, except that any occurrence of Bounded_String is replaced by Bounded_Wide_String, and any occurrence of package Bounded is replaced by Wide_Bounded. The specification of package Wide_Wide_Text_IO.Wide_Wide_Bounded_IO is the same as that for Text_IO.Bounded_IO, except that any occurrence of Bounded_String is replaced by Bounded_Wide_Wide_String, and any occurrence of package Bounded is replaced by Wide_Wide_Bounded. !corrigendum A.11(5/2) The specification of package Wide_Text_IO.Wide_Unbounded_IO is the same as that for Text_IO.Unbounded_IO, except that any occurrence of Unbounded_String is replaced by Wide_Unbounded_String, and any occurrence of package Unbounded is replaced by Wide_Unbounded. The specification of package Wide_Wide_Text_IO.Wide_Wide_Unbounded_IO is the same as that for Text_IO.Unbounded_IO, except that any occurrence of Unbounded_String is replaced by Wide_Wide_Unbounded_String, and any occurrence of package Unbounded is replaced by Wide_Wide_Unbounded. @dby The specification of package Wide_Text_IO.Wide_Unbounded_IO is the same as that for Text_IO.Unbounded_IO, except that any occurrence of Unbounded_String is replaced by Unbounded_Wide_String, and any occurrence of package Unbounded is replaced by Wide_Unbounded. The specification of package Wide_Wide_Text_IO.Wide_Wide_Unbounded_IO is the same as that for Text_IO.Unbounded_IO, except that any occurrence of Unbounded_String is replaced by Unbounded_Wide_Wide_String, and any occurrence of package Unbounded is replaced by Wide_Wide_Unbounded. !corrigendum A.16(68/2) @drepl @xcode<@b Copy_File (Source_Name, Target_Name : @b String; Form : @b String);> @dby @xcode<@b Copy_File (Source_Name, Target_Name : @b String; Form : @b String := "");> !corrigendum A.18.10(2/2) @drepl The declaration of the generic library package Containers.Indefinite_Vectors has the same contents as Containers.Vectors except: @dby The declaration of the generic library package Containers.Indefinite_Vectors has the same contents and semantics as Containers.Vectors except: !corrigendum A.18.11(2/2) @drepl The declaration of the generic library package Containers.Indefinite_Doubly_Linked_Lists has the same contents as Containers.Doubly_Linked_Lists except: @dby The declaration of the generic library package Containers.Indefinite_Doubly_Linked_Lists has the same contents and semantics as Containers.Doubly_Linked_Lists except: !corrigendum A.18.12(2/2) @drepl The declaration of the generic library package Containers.Indefinite_Hashed_Maps has the same contents as Containers.Hashed_Maps except: @dby The declaration of the generic library package Containers.Indefinite_Hashed_Maps has the same contents and semantics as Containers.Hashed_Maps except: !corrigendum A.18.13(2/2) @drepl The declaration of the generic library package Containers.Indefinite_Ordered_Maps has the same contents as Containers.Ordered_Maps except: @dby The declaration of the generic library package Containers.Indefinite_Ordered_Maps has the same contents and semantics as Containers.Ordered_Maps except: !corrigendum A.18.14(2/2) @drepl The declaration of the generic library package Containers.Indefinite_Hashed_Sets has the same contents as Containers.Hashed_Sets except: @dby The declaration of the generic library package Containers.Indefinite_Hashed_Sets has the same contents and semantics as Containers.Hashed_Sets except: !corrigendum A.18.15(2/2) @drepl The declaration of the generic library package Containers.Indefinite_Ordered_Sets has the same contents as Containers.Ordered_Sets except: @dby The declaration of the generic library package Containers.Indefinite_Ordered_Sets has the same contents and semantics as Containers.Ordereds except: !corrigendum D.5.1(18) @drepl @xindent<@s9<32 The rule for when Tasking_Error is raised for Set_Priority or Get_Priority is different from the rule for when Tasking_Error is raised on an entry call (see 9.5.3). In particular, setting or querying the priority of a completed or an abnormal task is allowed, so long as the task is not yet terminated.>> @dby @xindent<@s9<32 The rule for when Tasking_Error is raised for Set_Priority or Get_Priority is different from the rule for when Tasking_Error is raised on an entry call (see 9.5.3). In particular, querying the priority of a completed or an abnormal task is 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).>> !corrigendum G.2.2(11) @drepl Finally, S'Safe_First and S'Safe_last are set (in either order) to the smallest and largest values, respectively, for which the implementation satisfies the strict-mode requirements of G.2.1 in terms of the model numbers and safe range induced by these attributes and the previously determined values of S'Model_Mantissa and S'Model_Emin. @dby Finally, S'Safe_First and S'Safe_Last are set (in either order) to the smallest and largest values, respectively, for which the implementation satisfies the strict-mode requirements of G.2.1 in terms of the model numbers and safe range induced by these attributes and the previously determined values of S'Model_Mantissa and S'Model_Emin. !ACATS test None needed. !appendix From: Tucker Taft Sent: Wednesday, February 13, 2008 10:04 PM A document by Derek Jones indicated that the Ada 2005 standard had 22 occurrences of "must." Needless to say that surprised me. So I did a search. I found the following 14 "musts": 3.3.1(20.4) 3.9.4(26/2), 3.9.4(33/2) (both from an Example) 6.3.1(21.1) 7.5(9/2) (a Note) 12.6(16.1)(a Note) 13.3(8.1/2), 13.13.2(55/2), 13.13.2(56/2) C.7.2(30/2), C.7.2(32) ("must" is used in non-technical way) M(1/2), M.1(1/2), M.2(1/2), M.3(1/2) I'm not sure where the other 8 could be hiding. Only 9 of the above 14 are actually clear places where "shall" should have been used instead. The others are informal uses of "must." We might still want to purge them all, however, just to avoid any confusion about what are the real requirements. **************************************************************** From: Robert A. Duff Sent: Thursday, February 14, 2008 8:40 AM What document by Derek Jones are you talking about? I object to blindly changing "must" to "shall". Eschew obfuscation. Certainly the ones in "Language Summary" and "Examples" and other informal places can remain as is. The two in 3.3.1(20.4) can be fixed by changing "must precede" to "precede", which matches the style used in the immediately preceding paragraphs, and I think matches the general style of "Dynamic Semantics", which says what happens, not what "shall happen". In 6.3.1(21.1), "must be" should be "is"; it's a definition. In 13.3(8.1/2), I could tolerate changing "must include" to "shall include", but "includes" would be just as good. In 13.13.2(55/2), "must" should be "shall". In 13.13.2(56/2), "must" should probably be "shall". Annex M is informative, so should not use "shall". None of this has the slightest effect on implementers or users; as usual in such cases, I'm happy to take "!No Action". I get 22 occurrences, by the way: @ 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 capabilities of class-wide operations and type extension must be tagged, so objects of a given type must be represented with a given number of bits, or requiring late initialization must precede the initial value evaluations occurring earlier in the order of the component declarations must Queue must provide implementations for at least its four dispatching Queue, the implementation of the four inherited routines must be provided. 21.1/1 each attribute_designator in one must be the same as the corresponding assignment operation must be an aggregate or function_call, and such aggregates and function_calls must be built directly in the target formal_abstract_subprogram_declaration must be dispatching calls. See is implementation defined, but must include at least the storage element and of one the above checks, the implementation must ensure that the discriminants stream-oriented attribute must take place before this invocation returns. An time must be completely deterministic. For such implementations, it is programmer must make sure that the task whose attribute is being controlled manner. Each Ada implementation must document many characteristics implementation must document various properties of the implementation: manner. Each Ada implementation must document all implementation-defined certain target machine dependences. Each Ada implementation must document @ grep -i must rm.txt |wc 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. **************************************************************** From: Randy Brukardt Sent: Thursday, February 14, 2008 9:55 PM > > A document by Derek Jones indicated that the Ada 2005 > > standard had 22 occurrences of "must." Needless > > to say that surprised me. So I did a search. I see the new presentation AI will get started with a bang (for those of you who missed the recent meeting, we approved and closed the existing presentation AI as it was getting too long). I'm surprised, too, that despite some care we managed to forget that basic rule that many times. > > I found the following 14 "musts": > > > > 3.3.1(20.4) > > 3.9.4(26/2), 3.9.4(33/2) (both from an Example) > > 6.3.1(21.1) > > 7.5(9/2) (a Note) > > 12.6(16.1)(a Note) > > 13.3(8.1/2), 13.13.2(55/2), 13.13.2(56/2) > > C.7.2(30/2), C.7.2(32) ("must" is used in non-technical way) > > M(1/2), M.1(1/2), M.2(1/2), M.3(1/2) > > > > I'm not sure where the other 8 could be hiding. Umm, Tucker, there are 15 items in this list. That explains at least one that is "missing". There are 5 "must"s in the Introduction (paragraphs 11, 13, 19/2, 38, 41/2). I don't see any reason to change these. There are two "must"s in the single paragraph 3.3.1(20.4/2). There also are two "must"s in the note 7.5(9/2). > > Only 9 of the above 14 are actually clear places > > where "shall" should have been used instead. > > The others are informal uses of "must." We might > > still want to purge them all, however, just to avoid > > any confusion about what are the real requirements. > > What document by Derek Jones are you talking about? > > I object to blindly changing "must" to "shall". Eschew obfuscation. Certainly > the ones in "Language Summary" and "Examples" and other informal places can > remain as is. I think I agree. It's not worth changing. > The two in 3.3.1(20.4) can be fixed by changing "must precede" to "precede", > which matches the style used in the immediately preceding paragraphs, and > I think matches the general style of "Dynamic Semantics", which says what > happens, not what "shall happen". > > In 6.3.1(21.1), "must be" should be "is"; it's a definition. > > In 13.3(8.1/2), I could tolerate changing "must include" to > "shall include", > but "includes" would be just as good. > > In 13.13.2(55/2), "must" should be "shall". > > In 13.13.2(56/2), "must" should probably be "shall". > > Annex M is informative, so should not use "shall". What is the alternative? A quick attempt to use other words doesn't seem to work. Of course, leaving it as it is would be fine. OTOH, this is really just reiterating requirements given elsewhere, so I don't think "shall" is so bad. > None of this has the slightest effect on implementers or users; as usual in > such cases, I'm happy to take "!No Action". > > I get 22 occurrences, by the way: ... This didn't help any, as these are completely without (useful) context. Other than to verify the number! The search engine didn't help any, either - every page got matched whether it contained "must" or not.(I'm not quite sure why, but I'm not curious enough to go debug the code - one likely possibility is that it is a word that is omitted from indexing and there is some bug in the override code that is supposed to deal with the special case of finding unindexed words.) I ended up doing a text search on the HTML text, which came up with a small set of pages, and then searching each page individually in Firefox. > 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! Note that virtually every paragraph number in question has a /2 (meaning it was modified or new Ada 2005 wording). I'm embarrassed because this is something that I'm always explicitly looking for, and I'm surprised that I missed that many. (While the rest of you are also supposed to note such mistakes during editorial review, I get paid to find them, so I'm not happy when I fail to do so.) I don't recall ever doing a search for the word, though -- obviously we should have done that. **************************************************************** From: Tucker Taft Sent: Thursday, February 14, 2008 10:14 PM To answer Bob's question about "what document by Derek Jones are you talking about," he sent it to the OWGV mailing list. OWGV is an ISO working group focusing on language vulnerabilities. The document is called "Forms of language specification." I could ask him whether I could forward it to the ARG mailing list if there is sufficient interest. **************************************************************** From: Robert A. Duff Sent: Friday, February 15, 2008 7:09 PM > > Annex M is informative, so should not use "shall". ^^^ > What is the alternative? I think you missed the "not" -- that is, we agree that Annex M need not change. > I ended up doing a text search on the HTML text, which came up with a small > set of pages, and then searching each page individually in Firefox. Now you know why I like the .txt version! After doing the grep, I did an incremental search in Emacs. It's nice to have fancy fonts and formatting, but for searching and cut&paste into emails, you can't beat the plain old 7-bit ascii! (I concatenated all the *.txt files by hand, of course. 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 versions, but I thought I recognized some from Ada 83 -- particularly in the "Language Summary". I don't see any need for embarrassment. There are NOT 22 bugs -- just 22 cases to be looked at, and when I looked at them, I found only one case that definitely ought to be "shall", and one "probable" case. One and a half minor bugs isn't a big deal! (I looked at about 3/4 of the 22.) **************************************************************** !topic S'Safe_[l]{L}ast !reference Ada 2005 RM G.2.2(11) !author Grein 2008.04.23 **************************************************************** !topic Strange reference in 13.3(75) !reference 13.3(75), 3.9.2 !from Adam Beneschan 08-05-19 !discussion Presentation nitpick: 13.3(75) reads: S'External_Tag denotes an external string representation for S'Tag; it is of the predefined type String. External_Tag may be specified for a specific tagged type via an attribute_definition_clause; the expression of such a clause shall be static. The default external tag representation is implementation defined. See 3.9.2 and 13.13.2. The value of External_Tag is never inherited; the default value is always used unless a new value is directly specified for a type. Assuming someone reads this and then decides to follow the cross-references, it's reasonable to think they might try 3.9.2 first since it's listed first; but the effect is likely to be, "Huh? Why did it refer me here?" since 3.9.2 says nothing about external tags or anything related to them---at least, I don't see any connection. If the intent was that 13.13.2(29-34) is the section that discusses T'Class'Input and 'Output (which use the external tags), and those sections involve subprogram dispatching, perhaps it would be better to remove the 3.9.2 reference from 13.3(75) and put them in 13.13.2(29-34). Or, alternatively, was this 3.9.2 reference a typo (intended to be 3.9, which would make sense)? **************************************************************** !topic Wrong names in Wide_(Un)Bounded_IO package definitions !reference A.11(4-5), A.4.7, A.4.8 !from Adam Beneschan 08-06-11 !discussion A.11(4) says: The specification of package Wide_Text_IO.Wide_Bounded_IO is the same as that for Text_IO.Bounded_IO, except that any occurrence of Bounded_String is replaced by Wide_Bounded_String, and any occurrence ^^^^^^^^^^^^^^^^^^^ of package Bounded is replaced by Wide_Bounded. The specification of package Wide_Wide_Text_IO.Wide_Wide_Bounded_IO is the same as that for Text_IO.Bounded_IO, except that any occurrence of Bounded_String is replaced by Wide_Wide_Bounded_String, and any occurrence of package ^^^^^^^^^^^^^^^^^^^^^^^^ Bounded is replaced by Wide_Wide_Bounded. The names noted are incorrect: they should be Bounded_Wide_String and Bounded_Wide_Wide_String. There are similar errors in A.11(5). **************************************************************** !topic Wrong name, missing names in 3.9(25.1) !reference 3.9(25.1) !from Adam Beneschan 08-06-13 !discussion 3.9(25.1) lists Interface_Ancestor_Tag as one of the routines that raises Tag_Error if given a No_Tag argument. But the correct name is Interface_Ancestor_Tags (with an "s" at the end). Also, it lists Expanded_Name, but shouldn't it also list Wide_Expanded_Name and Wide_Wide_Expanded_Name? **************************************************************** !topic _statement !reference 9.6(22) !from Christoph Grein 2008-08-07 !discussion Quote: "..., the _statement is cancelled ..." Is the fragment _statement intentional here? (No, I guess. This is already in RM 95.) **************************************************************** From: Randy Brukardt Sent: Saturday, August 9, 2008 12:58 AM That is quite common in the RM 95; there were many such fragments around. I've been trying to get rid of them when we have a reason to change a paragraph anyway, but it doesn't seem important enough to do in general. (This sort of thing made a mess for the automatic syntax link generator for the HTML version of the Standard.) **************************************************************** From: Randy Brukardt Sent: Monday, July 6, 2009 7:42 PM The minutes of the Tallahassee ARG meeting say (under AI05-0001-1): Change the introductory paragraph to say "...change the contents {and semantics} of the package...". That makes it clear that the semantics also are changed. Really should make that change to all of the indefinite forms as well. The last sentence was intended to cover all of the *existing* indefinite forms as well as the new ones. **************************************************************** From: Bob Duff Sent: Wednesday, August 19, 2009 3:34 PM The NOTE at D.5.1(18) is misleading. Seems to imply that Set_Priority might raise Tasking_Error for a terminated task. But D.5.1(7) says it's ignored. Found by a customer of AdaCore, by the way. GNAT seems to incorrectly raise T_E. Probably a "maintenance error". I guess some earlier version of the RM required T_E, but wiser heads prevailed, but forgot to update the NOTE. And this part of the GNAT runtimes was probably written according to the earlier spec. **************************************************************** From: Christoph Grein Sent: Thursday, November 12, 2009 6:32 AM 13.3(8.1/3) The set of machine scalars is implementation defined, but include{s} at least the storage element and the word. "must" was removed, but then grammar requires singular. [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. ****************************************************************