Version 1.4 of ai05s/ai05-0092-1.txt
!standard 3.3.1(20.4/2) 08-07-11 AI05-0092-1/03
!standard 3.9(25.1/2)
!standard 6.3.1(21.1/2)
!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 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) Drop "must" from 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).
!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.)
[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).
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).
!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'.
!corrigendum 3.3.1(20.4/2)
Replace the paragraph:
- The assignments to any components, including implicit components, not
requiring late initialization must precede the initial value evaluations for
any components requiring late initialization; if two components both require
late initialization, then assignments to parts of the component occurring
earlier in the order of the component declarations must precede the initial
value evaluations of the component occurring later.
by:
- The assignments to any components, including implicit components, not
requiring late initialization precede the initial value evaluations for
any components requiring late initialization; if two components both require
late initialization, then assignments to parts of the component occurring
earlier in the order of the component declarations precede the initial
value evaluations of the component occurring later.
!corrigendum 3.9(25.1/2)
Replace the paragraph:
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.
by:
Tag_Error is raised by a call of Descendant_Tag, Expanded_Name, External_Tag,
Interface_Ancestor_Tags, Is_Descendant_At_Same_Level, or Parent_Tag if any tag
passed is No_Tag.
!corrigendum 6.3.1(21.1/2)
Replace the paragraph:
- each attribute_designator in one must be the same as the
corresponding attribute_designator in the other; and
by:
- each attribute_designator in one is the same as the
corresponding attribute_designator in the other; and
!corrigendum 13.3(8.1/2)
Replace the paragraph:
A machine scalar 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.
by:
A machine scalar 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.3(75/1)
Replace the paragraph:
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.
by:
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 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)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
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).
by:
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)
Replace the paragraph:
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.
by:
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.
by:
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 G.2.2(11)
Replace the paragraph:
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.
by:
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).
****************************************************************
Questions? Ask the ACAA Technical Agent