!standard 3.3.1(20.4/2) 08-03-05 AI05-0092-1/01 !standard 6.3.1(21.1/2) !standard 13.13.2(55/2) !standard 13.13.2(56/2) !class presentation 08-03-05 !status work item 06-03-05 !status received 06-02-13 !priority Low !difficulty Easy !qualifier Omission !subject 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) Drop "must" from 13.3(8.1/2). 4) Replace "must" by "shall" in 13.13.2(55-56/2). !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.) [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) Drop "must" from 13.3(8.1/2). 4) Replace "must" by "shall" in 13.13.2(55-56/2). !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). !corrigendum 3.3.1(20.4/2) @drepl @xbullet @dby @xbullet !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 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 include at least the storage element and the word. Machine scalars are used to interpret component_clauses when the nondefault bit ordering applies. !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). !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.) ****************************************************************