Version 1.16 of ais/ai-00114.txt

Unformatted version of ais/ai-00114.txt version 1.16
Other versions for file ais/ai-00114.txt

!standard 12.03 (11)          00-08-31 AI95-00114/00
!class confirmation 96-04-04
!status work item 96-04-10
!status received 96-04-04
!priority Low
!difficulty Hard
!subject Editorial Comments on AARM
!summary
This AI serves as a holder for editorial comments on AARM-only annotations. Because the AARM has no official status as far as ISO is concerned, these will be considered low priority.
If a change cross-references this AI, find it in the Appendix below.
!question
!response
!appendix

!section 12.3(11)
!subject but the{y} can be in instances.
!reference AARM95-12.3(11.x)
!from Keith Thompson 95-11-10
!reference 95-5384.a Keith Thompson 95-11-11>>
!discussion

****************************************************************
From: Randy Brukardt (Editor)
Date: August 30, 2000

This issue was fixed in AARM 6.0 (of course, no one except Bob has that
version :-).

****************************************************************
!section 12.3(11)
!subject It doesn't matter that [an] one could imagine ...
!reference AARM-12.3(11.dd)
!from Keith Thompson 95-11-17
!reference 95-5391.a Keith Thompson 95-11-17>>

****************************************************************
!section 13.3(12)
!subject Address clauses for components
!reference AARM95-13.3(12)
!from Keith Thompson 96-02-22
!reference 96-5429.a Keith Thompson 96-2-22>>
!discussion

The referenced paragraph in the AARM says:

        12   {specifiable [of Address for stand-alone objects and for
        program units]} {Address clause} Address may be specified for
        [stand-alone] objects and for program units via an attribute_
        definition_clause.

The use of square brackets around the phrase "stand-alone" implies that it
is redundant and can be proven from other rules.  How does the restriction
to stand-alone objects follow from other rules?  In particular, why is
this illegal (adapted from a posting to comp.lang.ada by Bob Gilbert)?

   protected Discretes is
      procedure Write(Settings : in Setting_List);
   private
      HW_Control : Discrete_HW_Control;
      for HW_Control use at Some_Legal_Address;
   end Discretes;

I'm not suggesting that it should be, just asking how it can be proven
from other rules.


****************************************************************
!section 13.3(12)
!subject Address clauses for components
!reference AARM95-13.3(12)
!reference 96-5429.a Keith Thompson 96-2-22
!from Bob Duff
!reference 96-5456.a Robert A Duff 96-4-8>>
!discussion

> The referenced paragraph in the AARM says:
>
>       12   {specifiable [of Address for stand-alone objects and for
>       program units]} {Address clause} Address may be specified for
>       [stand-alone] objects and for program units via an attribute_
>       definition_clause.
>
> The use of square brackets around the phrase "stand-alone" implies that it
> is redundant and can be proven from other rules.  How does the restriction
> to stand-alone objects follow from other rules?

Good question.

Apparently, we thought that it was implied by 13.1(6.a):

        6.a   Ramification:  The ``statically denote'' part implies that it
        is impossible to specify the representation of an object that is not
        a stand-alone object, except in the case of a representation item
        like pragma Atomic that is allowed inside a component_list (in which
        case the representation item specifies the representation of
        components of all objects of the type).  It also prevents the problem
        of renamings of things like ``P.all'' (where P is an
        access-to-subprogram value) or ``E(I)'' (where E is an entry family).

But I must admit that I don't see how this follows from the RM.

In any case, the square brackets are AARM-only material, so the ARG can
safely believe them, even if they don't strictly follow from other
rules.  That is, this is a bug in the AARM's use of brackets, but not a
bug in the RM itself.

>...  In particular, why is
> this illegal (adapted from a posting to comp.lang.ada by Bob Gilbert)?
>
>    protected Discretes is
>       procedure Write(Settings : in Setting_List);
>    private
>       HW_Control : Discrete_HW_Control;
>       for HW_Control use at Some_Legal_Address;
>    end Discretes;
>
> I'm not suggesting that it should be, just asking how it can be proven
> from other rules.

The above was intended to be illegal, and *is* illegal by 13.3(12),
despite its use of square brackets in the AARM.

Anwyay, I think this can be taken as an editorial comment on the AARM,
rather than a comment on the RM itself.

- Bob

****************************************************************
!section 13.3(12)
!subject Address clauses for components
!reference AARM95-13.3(12)
!reference 96-5429.a Keith Thompson 96-2-22
!reference 96-5456.a Bob Duff 96-03-08
!from Keith Thompson
!reference 96-5458.a Keith Thompson 96-4-8>>
!discussion

Bob Duff wrote:
> In any case, the square brackets are AARM-only material, so the ARG can
> safely believe them, even if they don't strictly follow from other
> rules.  That is, this is a bug in the AARM's use of brackets, but not a
> bug in the RM itself.
[...]
> Anwyay, I think this can be taken as an editorial comment on the AARM,
> rather than a comment on the RM itself.

I agree.  I hadn't realized (though I probably should have) that the
phrase "stand-alone" does appear in the RM, without the brackets.

****************************************************************
!section 13.1(14)
!subject Errors in example
!reference RM95-13.1(14)
!from Jorgen Bundgaard 96-03-07
!keywords
!reference 96-5434.a Joergen Bundgaard 96-3-7>>
!discussion

The example 13.1(14.c-e) contains other violations of the legality rules than
those marked with "-- Illegal!": types A1 and A2 should be general access
types, and the accessibility levels of the Obj1(17) and Obj2(17) should not be
statically deeper than that of access types A2 and A1, respectively.

****************************************************************
!section 3.9.2(20)
!subject Illegal use of names in 3.9.2 example
!reference AARM95-3.9.2(20.e)
!from Ivan B. Cvar 96-09-19
!keywords dispatching operations
!reference 96-5703.a Ivan B. Cvar 96-9-19>>
!discussion

The example in the Annotated Ada95 Reference Manual 3.9.2(20.e) fails
to compile because it references 2 type names that are not visible at
the point of use.

However, the meaning of the example is clear, despite the errors, but you
may want to repair the example for future releases.

with P1; with P2;
procedure Main is
    X : T2;                  --<<< ERROR: Should be P2.T2
    Y : T1'Class := X;       --<<< ERROR: Should be P1.T1
begin
    P2.Op_A(Param => X); -- Nondispatching call.
    P1.Op_A(Arg => Y); -- Dispatching call.
    P2.Op_B(Arg => X); -- Nondispatching call.
    P1.Op_B(Arg => Y); -- Dispatching call.
end Main;

****************************************************************
!section 7.3(7)
!subject Semantic Errors in AARM 7.3 Examples
!reference AARM-7.3(7.f)
!reference AARM-7.3(7.h)
!reference AARM-7.3(7.m)
!from Ivan B. Cvar 96-08-01
!reference 96-5629.a Ivan B. Cvar 96-8-1>>
!discussion

There are 3 unintended semantic errors in Annotated Ada 95 Reference Manual
clause 7.3, paragraphs 7.f, 7.h, and 7.m.  They are:

In the example of 7.3(7.f), the closing designator at the end of the
body of procedure Foo is wrong.  It should be Foo, not A.

In the example of 7.3(7.h), the named association in the discriminant
constraint denotes a discriminant named A, whereas the correct name is D,
as declared in paragraph 7.g.

In the example of 7.3(7.m), the package Q should have the context clause
"with P; use P" to make the name of type Parent visible, and for consistency
with 7.3(7.n) since 7.3(7.n) contains a with clause that denotes Q.

****************************************************************

!topic      Change from Ada 83 omitted
!reference  AARM-95 13.7 (37.d-38.d)
!from       Wes Groleau  98 Oct 06
!keywords   System  Null_Address  incompatibility
<<reference as: 1998-15927.a W. Wesley Groleau x4923 1998-10-6>>
!discussion In LRM-83, no equivalent of System.Null_Address is required.
	    Many vendors added it as an extension, but not all used the
	    same name.  AARM mentions UI-0065 (which I am still trying to
	    locate) but doesn't specifically say it is a change.  (Karl
	    Grebyn's Ada 83 Annotations do not mention any Ada-83
	    standardization issue for this, so I presume there wasn't one
	    until the 9X effort.)

****************************************************************

!topic Object freezing and aspect clauses
!reference RM95 13.14(19), 13.1
!from Adam Beneschan 11-18-02
!discussion

I believe there's an omission from RM95 13.1 on the subject of an
aspect clause on an object after the object is frozen.  It seems clear
to me that this was intended to be illegal.  13.14(19) says:

   An operational or representation item that directly specifies an
   aspect of an entity shall appear before the entity is frozen (see
   13.1)

where "entity" includes objects as well as types.  ACATS test bde0008
confirms that this is supposed to be illegal:

   type Enum is (Red, White, Yellow);
   ObjA : Enum;
   ObjB : Enum := ObjA;

   -- The nonstatic expression ObjA in the initialization expression of ObjB
   -- above freezes ObjA.  The representation clause is therefore illegal.
   -- RM 13.14(4,8,19);6.0

   for ObjA'Size use System.Storage_Unit;                             -- ERROR:
                                   -- Representation clause of a frozen object.

The reason I think there's an omission is that the Legality Rules in
13.14(16-19) are all supposed to be repeats of rules that are stated
elsewhere in the RM, and they all refer to other sections.  The above
rule refers to 13.1.  However, there appears to be no language in 13.1
that makes it illegal for an aspect clause on an *object* to appear
after the object is frozen.  13.1(9) and 13.1(9.1) make it illegal for
types and subtypes, but there's no similar language in 13.1 that
pertains to objects.

This appears to me to be a simple typo, but it should be fixed.

****************************************************************

From: Randy Brukardt
Sent: Friday, November 22, 2002  11:16 PM

The above comment has raised during the Corrigendum process, and was handled
at that time. Note that the comment is only on the AARM, as there is no
such thing as the RM rule "that is intended to be a repeat". If it's a
normative rule (and this one is), it applies.

We discussed this during the Corrigendum discussions. See the !appendix of
AI-137 (toward the bottom).

But the whole question is a bit silly. I don't see anything in 13.14(16-19)
that indicates that it is some sort of repeat. Certainly, it is normative
text in the standard. It's true that the Ada 95 AARM has the text in square
brackets, but the AARM isn't normative in any way.

There were several such AARM errors discovered before or during the
Corrigendum work. The updated AARM that includes the Corrigendum changes
does not include square brackets around 13.14(19) for this very reason: it
is not redundant. (There are a couple of other, similar cases in the updated
AARM.)

In any case, this appears to be a comment on the AARM, not on the
standard -- and the AARM change has already been made. So there is nothing
that needs to be done here.

****************************************************************

From: Randy Brukardt (Editor)
Date: August 30, 2000

I've made the corrections needed to implement the presentation issues
above in the updated AARM, or explained why the suggested correction was
not (and will not) be made.

Newer items below this item (if any) have *not* been handled. (They should be
on the updated AARM).

****************************************************************

From: Dan Eilers [dan@IRVINE.COM]
Sent: Wednesday, October 18, 2000 8:29 PM

!topic AI-00077 is undocumented extension to Ada83
!reference RM95-10.01.04
!from Dan Eilers
!keywords extension
!discussion

The AARM should mention that AI-00077 is an extension to Ada83.

[Editor's note: AI-00077 is a confirmation.]

****************************************************************

From: Dan Eilers [dan@IRVINE.COM]
Sent: Wednesday, October 18, 2000 8:33 PM

!topic AI-00163 is undocumented incompatibility with Ada83
!reference RM95-4.5.5(18-20)
!from Dan Eilers
!keywords incompatibility
!discussion

The AARM should mention that AI-00163 is an incompatibility with Ada83.

[Editor's note: AI-00163 is a confirmation.]

****************************************************************

From: Dan Eilers [dan@IRVINE.COM]
Sent: Wednesday, October 18, 2000 8:53 PM

!topic undocumented inconsistency regarding 'size
!from Dan Eilers
!keywords inconsistency
!discussion

The AARM should mention that 'size is inconsistent with Ada83,
as noted by Robert Dewar in his email attached to AI95-00163,
as well as recent ARG email:

> ...   (we have found the incompatibilities in handling of Size to be FAR
> more worrisome, since in general they cause different results with no
> complaint at compile time).
  ...
> If one user bumping into one incompatibility using one vendors compiler IS
> enough justification for changing the language, I have a number of messages
> to transmit to this list, starting with a complaint about what to me is the
> gratuitous change in the handling of static expressions that makes LOTS of
> Ada 83 programs illegal.

----

>       ...                                               The pragmatic
> issues are that Ada 95 pinned down some things left undefined in Ada 83,
> and did it in a manner which, while formally allowed by the 83 RM did
> not correspond to the way most compilers did things (e.g. mandating
> Natural'Size = Integer'Size - 1, which was clearly allowed by the
> Ada 83 RM, but all Ada 83 compilers I worked with had Natural'Size =
> Integer'Size [I have heard that the Intermetrics compiler had the
> Ada 95 treatment, but I am not familiar with that Ada 83 compiler].

****************************************************************

!topic Most operations that yield[s] a String
!reference AARM95-A.4.3(2.a)
!from Christoph Grein 02-01-07
!discussion

This typo is not a RM bug, since it is only in the AARM. Nevertheless it should
be corrected.

****************************************************************

From: John Barnes
Sent: Tuesday, November 23, 2004  11:02 AM

In C.7.1 we say Task_ID rather than Task_Id.

It seems to me to be better to use ID and to break the rule that only the
first letter is in caps. We do it consistently with IO.

However, I just noticed that AI-266 and maybe others use Task_Id.

And in 11.4.1 we have Exception_Id and Null_Id.

Would someone like to make a ruling on this? I assume that we could do a
global edit on the whole RM. Hmmm.

****************************************************************

From: Randy Brukardt
Sent: Tuesday, November 23, 2004  5:34 PM

My personal opinion is that Task_ID is wrong. "Id" is an abbreviation for
"Identifier", not an acronym of some sort. "IO" is an acronym for Input-Output.

However, the Standard is consistent in using Task_ID; only the defect reports
use Task_Id. It would be easiest to be consistent with that. OTOH, it occurs
only in 4 existing clauses (C.7.1, C.7.2, D.5, and D.11), so changing it
wouldn't be impossible.

****************************************************************

From: Pascal Leroy
Sent: Wednesday, November 24, 2004  9:34 AM

I agree with this. Only acronyms should be all caps.
We should be using Task_Id everywhere.

****************************************************************

From: Robert I. Eachus
Sent: Wednesday, December  3, 2003  7:53 AM

>Feel free to send such suggestions to me. I added some index entries for the
>Consolidated RM, and I'll be happy to do so again.

I just ran into one that is not marginal at all. 3.8(12) should appear
somewhere under discriminants in the index, for example:

discriminant
   use in a record definition 3.8(12)

This is the paragraph that requires that a discriminant must appear
alone in a record declaration: "A name that denotes a noninherited
discriminant is allowed within the declaration of the type, but not
within the discriminant_part. If the discriminant is used to define the
constraint of a component, the bounds of an entry family, or the
constraint of the parent subtype in a derived_type_definition then its
name shall appear alone as a direct_name (not as part of a larger
expression or expanded name). A discriminant shall not be used to define
the constraint of a scalar component."

Of course I could recommend that we remove the restriction instead. ;-)
But I just don't see that as a big deal.

****************************************************************

From: Pascal Leroy
Sent: Friday, November 26, 2004  8:39 AM

1.1.2(23.c) should say "certification" rather than "validation", because
we should be consistent with the terminology of 18009.

****************************************************************

From: Randy Brukardt
Sent: Monday, December 13, 2004  8:35 PM

The AARM note 3.3(22.a) is completely wrong; there is a legality rule that
all untagged view conversions are reversible. This presumably was leftover
from an early version of Ada 9x. Delete this rule.

****************************************************************

From: Dan Eilers
Sent: Monday, December 17, 2004  8:05 PM

Running spell check finds: (On the December 2004 draft AARM)

and and                 AA-3-10.html   [3.10(9.l) - ED]
as as                   RM-3-9-3.html  [3.9.3(1/2) - Error in draft - ED]
architechture           AA-13-13-1.html [13.13.1(9.a.1/1) - ED]
behaviour               Defect1.html
convinient              AA-11-3.html   [11.3(7.b/2) - Error in draft - ED]
declared declared       AA-3-9-3.html  [3.9.3(3/2) - Error in draft - ED]
Identificiation         Defect1.html
Internation             AA-0-1.html, RM-0-1.html [Intro(0.3) - Error in draft - ED]
interprestation         AA-11-5.html   [11.5(31.j/2) - Error in draft - ED]
is is                   AA-13-5-2.html, RM-8-5-1.html
				[8.5.1(5/2) - Error in draft; 13.5.2(4.a) - ED]
langauge                AA-D-14.html, AA-D-15.html, RM-D-14.html, RM-D-15.html
				[D.14(2/2), D.15(2/2) - Error in draft - ED]
mechansisms             AA-10-1-4.html  [10.1.4(7.d.1/1) - ED]
of of                   RM-10-1-1.html  [10.1.1(19/2) - Error in draft - ED]
overridding             AA-10-2-1.html, AA-8-5-4.html, RM-10-2-1.html
				[10.2.1(11.4/2) - Error in draft; 8.5.4(7.b.1/2) - ED]
preelaboratable         AA-0-29.html, AA-10-2-1.html, AA-11-4-1.html,
                        RM-0-29.html, RM-11-4-1.html
				[10.2.1(11.1/2) [index]; 11.4.1(2/2);
				 11.4.1(3/2); 11.4.1(19.aa/2) - Errors in draft - ED]
rules rules             AA-3-9-4.html   [3.9.4(12/2) - Error in draft - ED]
specifable              AA-13-1.html    [13.1(24.4/1) - ED]
that that               AA-3-9.html     [3.9(4.b/2) - Error in draft - ED]
the the                 AA-M.html, RM-M.html [3.5(37.a/2) - Error in draft - ED]
visiblity               AA-10-1-3.html  [10.1.3(18.b) - ED]

****************************************************************

From: Pascal Leroy
Sent: Monday, January 17, 2005  9:43 AM

8.2(12.a) is confused, it should say "cases involving generics".

****************************************************************

From: Erhard Ploedereder
Sent: Tuesday, January 18, 2005 12:37 PM

on the occassion of the pleasure of reviewing Chap 11, I traced consistency
of "True" vs "true", "False" vs. "false" for all references to the boolean
value in the RM. Amazingly consistent in favor of the upper-case, with a few
deviations that should be fixed:

"false" -> "False"
in
3.5.6(7)
D.10 (6,7,9)


"true" -> "True"
in
Language summary (28)
9.6.1 (72/2, 74/2)
D.6 (7)
D.10 (6,7,9)

Notes: The AARM always uses lower-case. I did not bother to keep
track. Occasionally, as in "the condition is true" in the RM, I let that
stand as a semantic statement rather than a reference to the literal
value (compared to "the condition evaluates to True")

****************************************************************

From: Gary Dismukes
Date: Thursday, January 20, 2005  1:16 PM

7.6(2.b) has the wrong word: "Calls on Finalize [happens] {happen} top-down;"

****************************************************************

From: Gary Dismukes
Date: Thursday, January 20, 2005  5:56 PM

12.5.1(23.a) needs a comma before which in the last sentence.

****************************************************************

From: Pascal Leroy
Sent: Tuesday, January 25, 2005  4:37 AM

3.5.9(18.e) uses "affect" rather than "effect".

****************************************************************

From: Pascal Leroy
Sent: Tuesday, January 25, 2005  4:40 AM

3.7(1.b) says a type and all of its subtypes have unknown discriminants if
it is declared that way. But that isn't true even in Ada 95; a partial view
may have unknown discriminants while the full view does not. Rephrase this
in terms of views.

****************************************************************

From: Pascal Leroy
Sent: Tuesday, January 25, 2005  4:43 AM

3.7(26.a) and 3.7(30.a) give a list of places where unknown discriminants are
allowed; in both places incomplete types are missing.

****************************************************************

From: Pascal Leroy
Sent: Tuesday, January 25, 2005  4:46 AM

3.8(11.a) says "specifiable". it should be "specified".

****************************************************************

From: Pascal Leroy
Sent: Tuesday, January 25, 2005  5:10 AM

In 4.1(17.c), change "...the name denotes [the] {a} value rather than..."
for consistency with the first part of the sentence.

****************************************************************

From: Pascal Leroy
Sent: Tuesday, January 25, 2005  5:23 AM

In 9.5.3(20.a), clarify the text by changing to "...lower than the {priority of
the} task initiating the abort."

****************************************************************

From: John Barnes
Sent: Wednesday, January 26, 2005  8:32 AM

In 12.5(7.c), change "a "interesting"" to "an "interesting"".

****************************************************************

From: Jean-Pierre Rosen
Date: Wednesday, March 2, 2005  2:03 AM

H.3.2(6.a): add "of". Well, native English speakers will tell if the current
phrasing is correct, but it looks strange to me.

****************************************************************

From: Pascal Leroy
Date: Monday, March 7, 2005  5:10 AM

I find the description in F.3.1(9) a bit puzzling.  It might be good to state
that it's not possible to create a value of type Picture that corresponds to
this combination. [Added an AARM note to clarify - ED]

---

In H.4(14.a), "parameter" is not appropriate. It should be "restriction".

---

J.3(6.a): Drop this Bobduffian comment. It doesn't help the reader.

---

J.7.1(23.b): "associate{d}".


****************************************************************

From: Randy Brukardt
Date: Monday, March 21, 2005  10:10 PM

13.7.1(12.b) is babbling about how some language-defined subprograms use
a Storage_Array. However, all of the routines referenced use a
Stream_Element_Array! While the point is true, it doesn't apply to any
language-defined subprograms, so it makes little sense to talk about it.

This AARM note belongs in 13.13.1, suitably changed to refer to
Stream_Element_Arrays.

****************************************************************

From: Randy Brukardt
Date: Sunday, April 3, 2005  10:20 PM

13.3(38.d) says "... an implementation might choose to make Component_Size be 0 for
an array of Booleans...". That would indicate that no space is allocated for
the components -- pretty weird. The rest of the paragraph makes it clear
that the size of 1 was meant.

****************************************************************

From: Randy Brukardt
Date: Saturday, April 9, 2005  7:50 PM

13.9.1(8.a), 13.9.1(8.c), and 13.9.2(12.c) talk about "static constraints all
the way down". But there is no such rule in the Standard. Tucker Taft believes
this is left over from an early draft of Ada 9X. These notes should be fixed
or removed.

****************************************************************

From: Randy Brukardt
Date: Sunday, April 3, 2005  11:20 PM

13.3(76.d) mentions that we don't use Storage_Array for portability. But this
is talking about a streams, so it should say Stream_Element_Array.

****************************************************************

From: Randy Brukardt
Date: Wednesday, April 13, 2005  3:30 PM

3.4(5.b) says that 3.4(5) [record extensions must be tagged] has to be
rechecked in the visible part of an instance specification. But that
is confusing, as the check on the generic template would reject any formal
that is not declared to be tagged (the properties of the formal being incorrect
for that kind of declaration), and no formal that is declared to be
tagged could turn out to not be tagged.

The note is actually talking about the "only if" part of the rule; that is,
a tagged type can only be extended with a record extension. There needs to be
an example explaining this.

****************************************************************

From: Dan Eilers
Sent: Thursday, April 14, 2005  3:40 AM

Here are the typos and doubled words: [This list has been edited to
include only words from existing text - ED]

aboved            AA-3-5-4.html  [3.5.4(9.a) - ED]
corrsponding      AA-A-4-4.html  [A.4.4(105.a) - ED]
deferencing       AA-H-4.html    [H.4(25.a) - ED]

****************************************************************

From: Tullio Vardanega
Date: Friday, May 6, 2005  8:33 AM

The acronym RTS (though possibly clear to the initiated) is
used twice in the whole AARM without ever being defined. It first
appears at 9.8(4.a) and then pops up in C.4(13.b). We should revert to
the expanded term as used elsewhere.

In C.7.2(28.b), "that have been Reference'd"
(instead of "for which the function Reference was invoked") reads
awkwardly.

****************************************************************

From: Gary Dismukes
Date: Friday, May 6, 2005  7:25 PM

Paragraph C.3.1(11.a) reads oddly to me:

  Reason: The intent is that aggregates all of whose scalar subcomponents
  are static, and all of whose access subcomponents are null, allocators
  for access-to-constant types, or X'Access, will be supported with no
  run-time code generated.

I think the comma after "are static" should be deleted.  Also, I would
change the "or" to "and" ("..., [or] {and} X'Access"), since all of these
are intended to be supported with no code.

[Editor's note: This note is only about aggregates, so the last part is
wrong.]

****************************************************************

From: Randy Brukardt
Date: Thursday, May 19, 2005  10:30 PM

3.4(17.d) says that "=" is not inherited for record extensions; but this
only applies to nonlimited record extensions.

****************************************************************

From: Randy Brukardt
Date: Thursday, May 19, 2005  10:45 PM

Someone complained about the spelling of "nonstatic" as "non-static" in
5.3(10.c).

****************************************************************

From: Christoph Grein
Date: Friday, June 10, 2005  1:03 PM

!topic Inconsistency in AARM explanation for aliased variables
!reference AARM05-3.10.2(41.b/2 .. d/2)
!from Grein 05-06-10
!keywords aliased 'Access
!discussion

This is a copy of the relevant paragraphs:

{AI95-00363-01} {incompatibilities with Ada 95} Aliased variables are
not necessarily constrained in Ada 2005 (see 3.6). Therefore, a
subcomponent of an aliased variable may disappear or change shape, and
taking 'Access of such a subcomponent thus is illegal, while the same
operation would have been legal in Ada 95. Note that most allocated
objects are still constrained by their initial value (see 4.8), and thus
legality of 'Access didn't change for them. For example:

  type T1 (D1: Boolean := False) is record
    case D1 is
      when False => C1: aliased Integer;
      when True  => null;
    end case;
  end record;

  type Acc_Int is access all Integer;
  A_T: aliased T1;
  Ptr: Acc_Int := A_T.C1'Access; -- Legal in Ada 2005, illegal in Ada 95
  A_T:= (D1 => True); -- Raised Constraint_Error in Ada 95, but does not
                      -- in Ada 2005, so Ptr becomes invalid when this
                      -- is assigned. 41.c/2 41.d/2

It seems to me that the comment on Ptr contradicts what is said before.
Also this declaration was legal in Ada 95. (At least Rational Apex let
this pass and I do not see why this should be illegal.)

****************************************************************

From: Randy Brukardt
Date: Friday, June 10, 2005  1:15 PM

> It seems to me that the comment on Ptr contradicts what is said before.
> Also this declaration was legal in Ada 95. (At least Rational Apex let
> this pass and I do not see why this should be illegal.)

Yes, it's backwards. "Illegal in Ada 2006, legal in Ada 95". There were some
others (on this same topic) with the same problem. They'll all be fixed in
the next draft.

****************************************************************

From: Dan Eilers
Date: Friday, June 17, 2005 12:13 AM

 Here are some typos:


inferfaces
   AA-1-2.html
   RM-1-2.html

namable
   AA-12-7.html
   AA-3-2-2.html
   AA-3-6.html
   AA-5-4.html

requiremnt
   AA-13-9-2.html

insure  -> ensure
   AA-13-13-2.html
   AA-13-14.html
   AA-13-3.html
   AA-13-5-3.html
   AA-6-5-1.html
   AA-D-2-6.html

affect of       -> effect of
   AA-D-2-1.html
   AA-M-2.html
   RM-M-2.html

no other effect than  -> no effect other than
   AA-12-2.html
   AA-9-4.html
   AA-B-1.html
   RM-12-2.html
   RM-9-4.html
   RM-B-1.html

****************************************************************

From: Pascal Leroy
Date: Friday, June 17, 2005  6:35 AM

13.5.1(1.b) says "pragma Bit_Order". But Bit_Order is an attribute, set
by an attribute_definition_clause.

13.7.2(5.a) should say "aliased" Object (otherwise Unchecked_Access is not
allowed, so the behavior is random). [Editor's note: 13.3(16) says that
Address only needs to provide a "useful result" if the prefix is aliased
or by-reference, so that's what this should say.]

****************************************************************

From: Christoph Grein
Date: Monday, June 20, 2005  2:35 AM

These have escaped your scrutiny (disjunct from Dan Eilers's list):

3.8 (12.e/2) [It] {They} also prevent circularities.

4.3.1(16.b/2) Note that [the] some of the rules

11.5(31.h/2) the new check on allocators (see 4.8{)}.

11.5(13) Shouldn't rem and mod be in bold face?
----
I hesitate to mention the follwoing because it's only a problem in the
coloured version of the AARM:

12.5.1(21/2) The new term progenitor is red in the later senteces of
this paragraph. It shluld be blue (three times).

****************************************************************

From: Christoph Grein
Date: Tuesday, July 12, 2005  3:03 AM

8.3(23.1/2) {visible (attribute_@!definition_@!clause)

8.3(26.i.3/1) [package A]

8.3(26.i.14/2) The context clause for Bad is illegal as I1 has an
implicit declaration of I1.G2 based on the generic child G1.G2, as well
was the mention of the explicit child I1.G2.
I do not understand the part beginning with "as well was".

8.3.1(8/2) The use of overriding_indicators allow{s} the detection

****************************************************************

From: Randy Brukardt
Date: Monday, August 8, 2005  11:08 PM

> 8.3(23.1/2) {visible (attribute_@!definition_@!clause)

That's not a typo, its a "feature" of the program -- it outputs the formatting
codes associated with index entries.

> 8.3(26.i.3/1) [package A]

OK.

> 8.3(26.i.14/2) The context clause for Bad is illegal as I1 has an
> implicit declaration of I1.G2 based on the generic child G1.G2, as well
> was the mention of the explicit child I1.G2.
> I do not understand the part beginning with "as well was".

It should say "as well as". And this is the technical use of "mention". Does it
make more sense now??

> 8.3.1(8/2) The use of overriding_indicators allow{s} the detection

This seems to be a plural phrase to me, thus "allow". But I'm not certain, and
Word is no help (it seems to be happy with either form). In any case, I'm not
going to change it without something more definitive.

****************************************************************

From: Gary Dismukes
Date: Tuesday, August 9, 2005  12:32 AM

The subject is "the use of ...", which is singular, so it should be "allows".

****************************************************************

From: John Barnes
Date: Tuesday, August 9, 2005  1:38 AM

I've scoured the Oxford dictionary, Fowler's Modern English usage and the
Latin dictionary for the word usus (4th decl) from which use comes. There is
no hint anywhere of it not behaving as a normal noun. I suggets therefore
that it should be treated as singular. It is the same structure as "The
howling of the cats is awful"

****************************************************************

From: Jeffery Carter
Date: Tuesday, August 9, 2005  8:49 PM

In American usage, the subject is "the use", which is singular. I'm not
so sure about British usage, which allows such things as "The band are
good tonight," which should be singular in American usage.

****************************************************************

From: Pascal Leroy
Date: Friday, August 12, 2005  4:12 PM

The last sentence of 13.5.1(1.a) doesn't make any logical sense. John
suggested changing it to "In the interest of uniformity, negative offsets..."
and I think that would be much better.

****************************************************************

From: Christoph Grein
Date: Friday, September 16, 2005  10:28 AM

13.11.2(17.a)
This is not a testable property, since we do not {know} how much

****************************************************************

From: Randy Brukardt
Date: Thursday, September 29, 2005  11:58 PM

> B.1(41.c)
> This paragraph is no longer correct since C++ has been an ISO
> standard for some time now.

I'm not sure what to do with this one. We didn't move the preceding
paragraph to real Implementation Advice, and it seems too late to do so now.
Moreover, such advice would seem to conflict with the normative wording
suggesting to use C for this purpose (that is, AI-376). So it's not clear to
me that that would be a good idea.

OTOH, I can't think of any justication for keeping 41.b as it is. So a
rewrite of 41.c doesn't make much sense.

This leads into the more general question of time-dependent notes in the
AARM. Do we try to update them all, or do we just leave old text alone with
the understanding that what was true in 1995 might not be true now? (I'm
pretty sure there are other cases like this in the AARM, but I can't point
to any offhand.)

Anyway, it seems to me that we have the following options:

1) Do nothing. (My preference).
2) Change just "(as of this writing)" to "(as of the writing of RM95)". But
then the note is still bogus, we're just more clearly blaming that on Bob
and Tuck.
3) Delete both 41.b and 41.c (41.b as being inconsistent with AI-376, and
41.c as it explains 41.b).
4) Hold up finishing the Amendment until we can discuss whether this should
be first-class Advice in B.3 (after 71.1, I suppose). Yuck.

Comments?

****************************************************************

From: Bob Duff
Date: Friday, September 30, 2005  11:07 AM

> 1) Do nothing. (My preference).
> 2) Change just "(as of this writing)" to "(as of the writing of RM95)". But
> then the note is still bogus, we're just more clearly blaming that on Bob
> and Tuck.
> 3) Delete both 41.b and 41.c (41.b as being inconsistent with AI-376, and
> 41.c as it explains 41.b).
> 4) Hold up finishing the Amendment until we can discuss whether this should
> be first-class Advice in B.3 (after 71.1, I suppose). Yuck.

I prefer 1, because it's easiest.  Second choice -- 2.

****************************************************************

From: Pascal Leroy
Date: Monday, October 3, 2005  1:55 AM

I think 41.b is still valuable.  An implementation might want to support
interfacing with C++ (beyond the subset that corresponds to C) and if it
does 41.b provides a modicum of uniformity.

I don't think we want to draw attention to the fact that we don't address
full-fledged interfacing with C++ in the Amendment, so making this a
first-class issue would be a bad idea.

I would suggest to merely drop the second sentence of 41.c and be done
with it: we recommend the identifier C_Plus_Plus, and we do so for
uniformity.

In addition we could change 41.b to read:

"If an implementation supports interfacing to the C++ entities not covered
by B.3, it should do so via the convention identifier C_Plus_Plus (in
additional to any C++-implementation-specific ones)."

That would have the advantage of being more consistent with the changes
that were made to B.3.

****************************************************************

From: Jean-Pierre Rosen
Date: Monday, October 3, 2005  4:24 AM

I would suggest:
5) Delete both 41.b and 41.c, and add the following to AI376:

Implementation advice:
If an implementation supports interfacing to C++ beyond the facilities
that are common with C, it should do so via the convention identifier
C_Plus_Plus (in additional to any C++-implementation-specific ones).

And have an E-mail ballot on this.

****************************************************************

From: Randy Brukardt (Editor)
Date: October 16, 2005

I've made the corrections needed to implement the presentation issues
above in the updated AARM (Amendment 1 version), or explained why the suggested
correction was not (and will not) be made. Such changes are marked with
a cross-reference to this AI.

Newer items below this item (if any) have *not* been handled. (They should be
on the updated AARM).

****************************************************************

From: Pascal Leroy
Date: Thursday, April 20, 2006

[Editor's note: The complete discussion is filed in AC-00129. This needs
clarification in the AARM, since we're not going to change the wording.]

> Well, we clearly went out of our way to define Name
> Resolution Rules for 'Access, so that argues for your
> interpretation. But then there can be no grey areas: the
> prefix is resolved using no context whatsoever (even thought
> that is hard) for all attributes other than 'Access and
> 'Unchecked_Access. I don't think we can cheat about what are
> and are not resolution rules, because it really does affect
> the legality of some programs. This isn't an area where its
> OK for implementations to differ.

I have always assumed that (1) was the intent of the RM, but I agree that
the words could be clearer.

****************************************************************

From: Randy Brukardt (Editor)
Date: May 15, 2006

I've made the corrections needed to implement the presentation issues
above in the final updated AARM (Amendment 1 version), or explained why the
suggested correction was not (and will not) be made. Such changes are marked
with a cross-reference to this AI.

Newer items should be filed in AI05-0005-1.

****************************************************************


Questions? Ask the ACAA Technical Agent