!standard 6.6 (6) 11-11-11 AI12-0005-1/00 !class confirmation 11-11-11 !status received 11-11-11 !priority Low !difficulty Easy !qualifier Omission !subject Editorial comments on AARM 2012 !summary This AI serves as a holder for editorial comments on AARM-only annotations. This AI serves the same purpose as AI95-00114 did for Ada 2005 and AI05-0005-1 did for Ada 2012. 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 From: John Barnes Sent: Tuesday, May 22, 2012 3:11 PM ... Anyway, I just downloaded the latest version and hunting around for incomplete types and generics, I came across 12.5(16.i/3). It refers to AI-215 instead of AI-213. Rats. **************************************************************** From: Randy Brukardt Sent: Monday, January 14, 2013 9:26 PM AARM 3.9(12.d/2) uses "privateness", which is not a word. Use "privacy" instead. **************************************************************** From: Randy Brukardt Sent: Monday, January 14, 2013 9:26 PM AARM 9.6.1(4.a/2) has two minor errors. First there is a word missing: "... which are more than 12 hours {different }than UTC. ..." Second, "southern" is misspelled (the last 'n') is missing. **************************************************************** From: Randy Brukardt Sent: Friday, April 19, 2013 1:21 AM AARM 11.5(31.l/3) has a typo: ...inlining is never requir{ed}[ing],... **************************************************************** From: Tucker Taft Sent: Tuesday, February 26, 2013 5:10 PM I agree with both of you. [Editor's Note: The majority of this thread can be found in AC-00248.] The wording as given is inadequate, but the intent is as Randy stated: you may assume that if you evaluate an assertion expression once and it is True, you don't need to evaluate it again if all you are doing in the mean time is evaluating assertion expressions. *************************************************************** From: Steve Baird Sent: Tuesday, February 26, 2013 5:21 PM I'm happy to leave it at that. Let's either take no further action or, if anyone thinks it is worth the bother, add a brief AARM note based on Tuck's words above. *** Add an AARM note. *************************************************************** From: John Barnes Sent: Friday, June 7, 2013 9:13 AM The package Ada.Dispatching was Pure in Ada 2005 but has been downgraded to Preelaborable because of the addition of Yield. This is unlikely to be a problem. (AI-166, D.2.1) *** Incompatibility not mentioned in AARM When an inherited subprogram is implemented by a protected function, the first parameter has to be an in parameter, but not an access to variable type. Ada 2005 allowed access to variable parameters in this case; the parameter will need to be changed to access to constant by the addition of the constant keyword. (AI-291, 9.4) *** this is a BI, but it doesn't say correction in AARM *************************************************************** From: Randy Brukardt Sent: Monday, June 15, 2013 9:43 PM 3.10.2(7.b/2) talks about anonymous access types used in stand-alone type declarations and function results as having the level of the declaration. But neither of these are true anymore (they also have special rules). This note needs to be rewritten to talk only about components. *************************************************************** From: Randy Brukardt Sent: Thursday, October 24, 2013 9:43 PM The thread in AC-00254 makes it clear that the "resolution" rules 4.6(7) and 6.4.1(4) are not actually used for resolving overloading and the like. They exist specifically to prevent the "name" from being evaluated (which would happen by 4.4(10)) if they are part of an expression. That's why they used the weird wording of "interpreted as" rather than "shall be". This needs to be much clearer in the AARM Notes. AC-00254 has an example program that illustrates some of the oddities that would occur if these rules were used as resolution rules. Tested compilers do not do so, thus we add the notes to ensure that future compiler authors are not confused. *************************************************************** From: Steve Baird Sent: Friday, November 15, 2013 4:57 PM unhyphenated "class wide" in 6.5(5.d/3) "if the result type is class wide, then there must be an expression ..." *************************************************************** From: Randy Brukardt Sent: Wednesday, December 11, 2013 9:43 PM There is an unhyphenated "classwide" in 6.8(5.b/3). "...and the static classwide accessibility check cannot fail..." There are also occurrences in 3.7.2(3.b/3) [two occurrences], 7.6.1(9.b/3), 7.6.1(24.ee/3), and E.2.2(20.j/3). *************************************************************** From: Adam Beneschan Sent: Tuesday, February 4, 2014 10:03 AM Is there a reason why the Shift_*** and Rotate_*** subprograms defined in Interfaces (in B.2) aren't listed in Q.3, or was this an oversight? They also don't have their own Index entries. (By contrast, the subprograms in Interfaces.C, defined in B.3, are in both places.) *************************************************************** From: Randy Brukardt Sent: Wednesday, February 5, 2014 6:51 PM I can't find any documentation of the reason, but I think I omitted them because the contents of package Interfaces is formally implementation-defined. (See B.2(1) and especially AARM B.2(1.a)). As further evidence of this reasoning, note the difference between the handling of these packages for restriction "No_Implementation_Identifiers". In particular, all identifiers in Interfaces are considered implementation-defined (13.12.1(2.11/3) and 13.12.1(2.15/3)), while only added identifiers in Interfaces.C are considered implementation-defined (13.12.1(2.2/3) and 13.12.1(2.6/3)). As such, they're not "language-defined" identifiers and thus they don't belong in Annex Q. Note that you don't find Long_Integer or Short_Integer in Annex Q, either. (Given the special handling for Long_Integer and Long_Float for the purposes of restriction No_Implementation_Identifiers, perhaps they ought to be there.) They probably ought to be in the main index, but I probably forgot about them simply because the usual command does all of that automatically (it adds a subprogram to the Annex Q and main indexes with a single operation). Since I'm not using the usual command, I ended up not using any command. I'll fix that for future versions. P.S. Note that the indexes are non-normative, so these are treated like questions on the AARM; so this thread will be filed in AI12-0005-1 with other AARM questions. *************************************************************** From: Adam Beneschan Sent: Wednesday, February 5, 2014 7:21 PM > I can't find any documentation of the reason, but I think I omitted > them because the contents of package Interfaces is formally > implementation-defined. (See B.2(1) and especially AARM B.2(1.a)). B.2(1.a) looks a lot like 13.7(2.a/2), and the identifiers in System do appear in Annex Q. But I'll allow there are other differences there. 13.7(2) says "The following language-defined library package exists" about System, while B.2(2) doesn't use the word "language-defined". Also, the description of No_Implementation_Identifiers lists System in the same category as Interfaces.C. I guess it seems a bit odd to have an identifier that is "implementation-defined" as opposed to language-defined, but that the language requires implementations to define (since it's in the Implementation Requirements section). Also, the language does seem to define what the identifier is supposed to do. Perhaps these identifiers are is in some in-between state between language-defined and implementation-defined---a "Schrödinger's Identifier", maybe? Anyway, I was just wondering if the omission was a typo. If there's a reason behind it, that's OK with me (I don't normally look things up in Annex Q anyway). *************************************************************** From: Randy Brukardt Sent: Wednesday, February 5, 2014 8:04 PM ... > I guess it seems a bit odd to have an identifier that is > "implementation-defined" as opposed to language-defined, but that the > language requires implementations to define (since it's in the > Implementation Requirements section). Also, the language does seem to > define what the identifier is supposed to do. Perhaps these > identifiers are is in some in-between state between language-defined > and implementation-defined---a "Schrödinger's Identifier", maybe? I think that's right. The problem here is while there is a requirement that an implementation define a function Rotate_Left, the first argument to it has a type that is clearly implementation-defined. (Most implementations will have Unsigned_8, but other possibilities exist: our U2200 implementation had Unsigned_9 but no Unsigned_8, for instance.) So it's in a weird limbo halfway between language-defined and implementation-defined. Since 13.12.1 comes down on the side of implementation-defined, the Annex Q indexes do the same. > Anyway, I was just wondering if the omission was a typo. If there's a > reason behind it, that's OK with me (I don't normally look things up > in Annex Q anyway). The omission from the main index was clearly an oversight (although "rotate" and "shift" are indexed). The omission from Annex Q was on purpose, I think. *************************************************************** Summary of private discussion between Steve Baird and Randy Brukardt, Wednesday, February 26, 2014 Baird: Given X : constant Positive := 0; is X a static constant? Brukardt: Yes, of course X : constant Positive := 0; is a static constant that's legal (and raises Constraint_Error at runtime). It's weird but causes no problems, and any other answer would be incompatible (see ACATS test B490001) and very bad for conditional compilation. It causes no problems because no code/types/whatever that will ever execute can depend on the value of X, and the value of the static expression is well-defined (so we always know what to do at compile-time). It's necessary so that conditional compilation works: if Static > 0 then declare Bits : constant Positive := Static; type Foo is range 0 .. (2**Bits)-1 with Size => Bits; begin ... We don't want the legality of Foo to depend on the *value* of Static (which it would if Bits is not a static constant when Static = 0), else the entire conditional compilation idea falls over. [4.9(34) causes many other such problems -- 2**Bits shows one of them -- but we certainly don't want to introduce any more. Recall the hoops we jumped through to allow conditional expressions to work as expected.] Cases like the above show that the compatibility issue is significant, thus no change of any kind is best. Maybe we want an AARM note, but no more. Baird: > It's weird but causes no problems, and any other answer would be > incompatible (see B490001) and very bad for conditional compilation. B490001's constant declaration would still be legal if we changed the definition of "static constant" to include a requirement that the static value belongs to the static subtype of the constant. But your are still right that it could be incompatible. This example is currently legal, but would become illegal: X : constant Positive := 0; function Foo return Natural is ... ; begin case Foo is when X => ...; when Positive => ...; end case; So I agree that we would need a good reason to make such a change. Is there any problem with having a static constant whose elaboration raises an exception? Does this cause problems with preelaborability, purity, the DSA, etc. ? Brukardt: I was asking you that! I can't think of any, specifically because the static value (presuming the expression is otherwise legal) is well-defined. In this case, 0. So the compiler just uses that (which it has to be able to do), and nothing that depends on that value can ever actually be executed, so there is no real problem. I suppose you might get funny errors in some cases: X : constant Positive := 0; B : constant Boolean 10/X; -- Illegal, divide-by-zero which is of course weird because you divided by a Positive value to ensure that you couldn't divide by zero. But I don't see that as worse than any other conditional compilation related errors. Purity seems to be syntactic (constant vs. variable). Preelaboration seems to be better with the current rule. If we changed it, then preelaboratability could depend on an imported value: X : constant Positive := Other_Pkg.Static; Y : constant Positive := X + 1; -- Better be static. If X is not a static constant when Other_Pkg.Static = 0, then Y is not allowed in a preelaborable package. That seems like a maintenance hazard (someone changes a value, a package far away becomes illegal for an obscure reason, and the fix is definitely non-trivial). Note that C.4(11) seems to cover this case, not requiring no code to be executed if the declaration raises an exception during elaboration. I'm not going to try to figure out DSA. *************************************************************** From: Randy Brukardt Sent: Friday, April 18, 2014 9:44 PM 13.14(10.m/3) has: type Bar is access function Foo (A : in Natural) return Natural; But the syntax of an access-to-subprogram does not have an identifier where Foo is given; it should be deleted. *************************************************************** !topic Ada.Direct_IO: Index after Create resp. Open !reference Ada 2012 RM A.8.2(3/2,7) !from Christoph Grein 2014-09-25 !discussion Neither Create nor Open specify the value of Index, which will be used for Read or Write, see A.8.5(3,6,11), for the very first access with the procedures without the Positive_Count parameter (must be 1, of course). Should this oversight be corrected? [Editor's note: Most of this thread is filed in AC-00264.] *************************************************************** From: Egil Harald Hoevik Sent: Thursday, October 2, 2014 1:33 AM I believe that's covered by A.8(3-4) *************************************************************** From: Randy Brukardt Sent: Thursday, October 2, 2014 1:51 PM > I believe that's covered by A.8(3-4) Thanks! A.8(4) says "When a direct file is opened, the current index is set to one." Hardly could be any clearer than that. Perhaps it isn't in the best possible place, but it certainly is stated normatively. [Editor's note: I added AARM notes to make this cross-reference more obvious.] *************************************************************** From: Randy Brukardt Sent: Friday, October 10, 2014 8:58 PM 13.11.3(9.c/3) does not mention aspect Default_Storage_Pool (see 13.11.3(5/3)). *************************************************************** From: Randy Brukardt Sent: Friday, February 13, 2015 8:12 PM 13.1.1(4.b/3) does not mention expression_function_declaration, it should be added directly after null_procedure_declaration. *************************************************************** From: Steve Baird Sent: Tuesday, March 10, 2015 6:48 PM There may be no problem here, but the wording seems unclear to me. If you think it is clear enough, I'll probably shut up (I say "probably" just to reserve the right to change my mind). In 4.1.6, we've got a new note The Constant_Indexing and Variable_Indexing aspects cannot be redefined when inherited for a derived type, but the functions that they denote can be modified by overriding or overloading. I don't think the 4.1.6 wording makes it sufficiently clear that the set of one or more functions denoted by a C_I/V_I aspect is recalculated when we declare an extension. For example, if an ancestor type has C_I specified which denotes two functions, might a descendant of that type have three C_I functions with one inherited, one overriding, and one non-overriding? Presumably yes. If the descendant type overrides an inherited C_I function of the ancestor type, which function body gets executed for an indexing call if the prefix is not class-wide? Presumably the overrider's. How does all this work in a case like package Pkg1 is type T1 is tagged null record with Constant_Indexing => Foo; function Foo (X : T1; Y : Integer; Z : Integer := 123) return T1; end Pkg1; package Pkg2 is type T2 is new Pkg1.T1 with record F2 : Integer := 0; end record; overriding function Foo (X : T2; Y : Integer; Z : Integer := 456) return T2; end Pkg2; Aaa : Pkg.T2; Bbb : Pkg.T2 := Aaa (789); ? Presumably this is legal and the non-dispatching call returns a T2, not a T1 (and the actual parameter passed in for Z is 456, not 123). It also seems a little odd that the equivalence rule which defines the dynamic semantics of these guys (4.1.6 (17/3)) occurs in a "Name Resolution Rules" section. *************************************************************** From: Steve Baird Sent: Wednesday, March 11, 2015 1:42 PM > If you think it is clear enough, I'll probably shut up (I say > "probably" just to reserve the right to change my mind). After sleeping on it, I see that the crux of the matter is the name resolution rule When a generalized_indexing is interpreted as a constant (or variable) indexing, it is equivalent to a call on a prefixed view of one of the functions named by the Constant_Indexing (or Variable_Indexing) aspect of the type of the indexable_container_object_prefix with the given actual_parameter_part, and with the indexable_container_object_prefix as the prefix of the prefixed view. and, specifically, the meaning in the case of a derived type which inherits the aspect of the phrase "the functions named by the Constant_Indexing (or Variable_Indexing) aspect of the type" . I know what set we want that phrase to denote (it is the set of subprograms where the equivalent prefixed call would work as defined in 4.1.3(9.2/3)). My question is whether the current wording captures that intent. I think maybe it does and there is no problem, but I raise the question. *************************************************************** From: Randy Brukardt Sent: Wednesday, March 11, 2015 2:38 PM I agree ("maybe it does"). The wording says "named by" and not the more usual "denoted by"; this means that it is the name of the function and not the declaration that is denoted that matters. Thus one starts with the name each time and then must figure out from that what is denoted. Obviously, that might be different for a derived type vs. the original type. What's not 100% clear to me is the implied (re-)resolution. Since one has a name by the rule, and one needs a declaration in order to make a call, I don't see how else one could arrive at a declaration. But it's not spelled out. Of course, that's typical of name resolution rules; the actual name resolution tends to be implicit in them. Thus I conclude that there is no problem (although perhaps adding an additional sentence to 4.1.6(17.c/3) would help future readers: "This equivalence is then resolved in the normal way; the aspect specifies a name, it does not denote declarations.") *************************************************************** Editor's note (April 2, 2015): All of the items above this marker are included in the Corrigendum version of the AARM. **************************************************************** From: Tucker Taft Sent: Sunday, April 26, 2015 5:54 PM There is some lack of clarity in the RM relating to the use of a subtype with a Static_Predicate that is declared in the scope of an "Ignore" Assertion_Policy. For example, in AARM 5.4(13, 13.a) it says the following: 13 Otherwise (the value is not covered by any discrete_choice_list, perhaps due to being outside the base range), Constraint_Error is raised. 13.a Ramification: In this case, the value is outside the base range of its type, or is an invalid representation. 13.a is not correct in the presence of subtype predicates. An object can have a "valid representation" and still have a value that does not satisfy its Static_Predicate, and hence not be covered by any choice list. This is easy to accomplish if "pragma Assertion_Policy(Static_Predicate => Ignore)" applies when the subtype is declared. Hence 13.a should be refined to include the case of a value that does not satisfy a Static_Predicate. It should also be clarified that X'Valid being False does *not* mean that X has an invalid representation. If X is in the appropriate range, but does not satisfy the predicates of its nominal subtype, then X'Valid will return False, but X is still "valid." This is confusing, and probably deserves a "user note" somewhere. More generally it might be appropriate to augment the AARM implementation notes that say what happens with subtypes with Static_Predicates that are being ignored. In particular, it should be clarified that, given an object X of such a subtype S, Constraint_Error is a possible outcome in "case" statements with X as the case expression (the situation described in 5.4(13,13.a) above), membership test "X in S" might return False, X'Valid might return False, etc. Be that as it may, this is *not* erroneous execution. The results are totally predictable, repeatable, and portable (and potentially confusing ;-). *************************************************************** From: Robert Dewar Sent: Sunday, April 26, 2015 7:05 PM the case statement should definitely raise CE in my view (P.S. that is the current treatment in GNAT). *************************************************************** From: Jeff Cousins Sent: Monday, April 27, 2015 4:14 AM 5.4 13.a needs updating, but it's pretty clear from 5.4 13, 3.8.1 10.1/3, 11.4.2 10/3 and 4.9 26/3 that there should be a Constraint_Error. *************************************************************** From: Randy Brukardt Sent: Monday, April 27, 2015 10:36 AM ... > 13.a is not correct in the presence of subtype predicates. > An object can have a "valid representation" and still have a value > that does not satisfy its Static_Predicate, and hence not be covered > by any choice list. This is easy to accomplish if "pragma > Assertion_Policy(Static_Predicate => Ignore)" applies when the subtype > is declared. Hence 13.a should be refined to include the case of a > value that does not satisfy a Static_Predicate. This just looks like a case where the editor (me) and the AI author (Bob) failed to notice that AARM note needs updating. Hardly a big deal. > It should also be clarified that X'Valid being False does > *not* mean that X has an invalid representation. If X is in the > appropriate range, but does not satisfy the predicates of its nominal > subtype, then X'Valid will return False, but X is still "valid." This > is confusing, and probably deserves a "user note" somewhere. In hindsight, this probably was a mistake; we should have left 'Valid to validity and let people that wanted to get the predicates involved to use memberships. But it is what it is; it's water over the bridge or under the dam now. :-) Perhaps a note is worthy. Are you drafting one?? (Or do I have to do *everything*? :-) > More generally it might be appropriate to augment the AARM > implementation notes that say what happens with subtypes with > Static_Predicates that are being ignored. In particular, it should be > clarified that, given an object X of such a subtype S, > Constraint_Error is a possible outcome in "case" > statements with X as the case expression (the situation described in > 5.4(13,13.a) above), membership test "X in S" > might return False, X'Valid might return False, etc. Be that as it > may, this is *not* erroneous execution. The results are totally > predictable, repeatable, and portable (and potentially confusing ;-). That seems unnecessary. This happened to be the absolute top priority on my testing list (it has been for quite a while); that's partly because I had sorted all of the items with the same priority in clause order, and something in 3.2 doesn't have much chance of anything with the highest priority to occur in front of it. Anyway, I wrote those tests (two) tonight, so the ACATS now checks that memberships, 'Valid, and for loops use the predicates even if disabled (and that the checks are not actually made in subtype conversion contexts). So it's hardly likely that any implementor will not be aware of those effects. I just added an objective for 5.4(13) to check the Constraint_Error case (it was previously marked as untestable, but clearly this case is testable). Since it would be based on the test I wrote tonight, it probably will get written in the coming weeks, so that shouldn't surprise anyone, either. (Especially after we fix the AARM note.) *************************************************************** From: Bob Duff Sent: Friday, May 15, 2015 5:50 AM > This just looks like a case where the editor (me) and the AI author > (Bob) failed to notice that AARM note needs updating. Hardly a big deal. I admit that when I wrote that AI, I wasn't thinking about Assertion_Policy. So I'm not surprised there are bugs related to that. *************************************************************** From: Randy Brukardt Sent: Monday, May 18, 2015 8:25 PM AARM 3.9(18.c/2), referring to Generic_Dispatching_Constructor, says: Note that any tagged type will match T (see 12.5.1). T is declared: type T (<>) is abstract tagged limited private; The issue here is that while the note for formally correct, it fails to note that some instances would be illegal anyway. Specifically, if the tagged type A is a tagged incomplete view (from an incomplete type, formal incomplete type, or limited with), using it as the actual in an instance of Generic_Dispatching_Constructor is illegal by rule (an actual type for a formal private type is not one of the places listed where the name of an incomplete view is allowed). Similarly, if the tagged type A is a tagged partial view before its completion (from a private type or private extension), using it as the actual in an instance of Generic_Dispatching_Constructor is illegal because the type will be frozen by the instantiation, but that would violate 13.14(17) [or, if you prefer, 7.3(5), or even 3.11.1(8) -- this rule is repeated three times in the RM!]. Thus I suggest a simple rewrite of the AARM annotation: Note that {almost} any tagged type {can be used in an instance of Generic_Dispatching_Constructor}[will match T (see 12.5.1)]. {Using a tagged incomplete view or a tagged partial view before the completion of the type in such an instance would be illegal; all other tagged types can be used in an instance of Generic_Dispatching_Constructor.} *************************************************************** From: Tucker Taft Sent: Monday, May 18, 2015 10:05 PM That's fine with me, though I don't think it is necessary. Incomplete types are just that, incomplete, and are not really "types" in the normal sense. Also, freezing is almost always treated as an orthogonal issue. *************************************************************** From: Randy Brukardt Sent: Monday, May 18, 2015 11:05 PM Sure, if you're in language lawyer mode. (Although an incomplete type is surely a (view of a) type; thinking it's not "really a type" caused all manner of RM holes -- let's not go back there!) But I definitely don't like saying "all" or "any" when we really mean "most". We have a strict no lying rule for the AARM. I realize that strictly speaking, the note *isn't* lying (the matching works, other rules fail). But that seems like hair-splitting; only a language lawyer will care precisely why something fails. Besides, I believe I wrote that note (I wrote most of the Generic_Dispatching_Constructor proposals), and I think I meant that you can instantiate the generic with any tagged type (assuming you have an appropriate constructor function) -- which definitely is not true. I did think about just sticking "complete" into the sentence (or maybe channelling the old commercials with "virtually spotless" dishes and saying "virtually all" :-), but I thought a more complete explanation would be more useful. The private type case is not that obvious and bites people all the time (that's why we've spent so much effort on work-arounds and alternative rules), best to not sweep it under the rug as "just freezing, we don't need to talk about that". *************************************************************** From: Tucker Taft Sent: Tuesday, May 19, 2015 7:05 AM > ... But I definitely don't like > saying "all" or "any" when we really mean "most". We have a strict no > lying rule for the AARM. ... Fair enough. Go for it. *************************************************************** From: Jeff Cousins Sent: Wednesday, May 27, 2015 6:33 AM Randy's words seem an improvement. *************************************************************** !topic Ruined paragraph !reference 2012 RM3.10.2(20) !from Christoph Grein 16-02-19 !discussion This paragraph is a bullet with an incomplete sentence. This is the previous version: For determining whether one level is statically deeper than another when within a generic package body, the generic package is presumed to be instantiated at the same level as where it was declared; run-time checks are needed in the case of more deeply nested instantiations. This is the new content: or generic function F It looks like an error - there is no reason to insert "generic function" in this paragraph - and also no /4 indication. *************************************************************** From: Randy Brukardt Sent: Monday, March 21, 2016 11:33 PM There's a chunk of junk in the consolidated RM that gets its own paragraph number (as would happen with any junk floating around); there's nothing wrong with the actual text (it just moved down one paragraph). Since the problem is only in the consolidated RM (and not in the Corrigendum or Ada 2012 Standard, the official documents), we just mention it here and fix it without further ado. [Unfortunately, Christoph then raised some further ado - Editor.] *************************************************************** !topic Ruined paragraph !reference 2012 RM3.10.2(20) !from Christoph Grein 16-03-24 !discussion I resend this since I've never received a reply from the list, so I suspect the mail was lost somehow. The error is in the version http://ada-auth.org/standards/rm12_w_tc1/RM-Final.pdf but not in http://ada-auth.org/standards/aarm12_w_tc1/html/AA-3-10-2.html Oh, now I see: the paragraph (20) is erroneously present. When removed, the text is correct again. I haven't checked the other versions. -------- Weitergeleitete Nachricht -------- Betreff: Ruined paragraph Datum: Fri, 19 Feb 2016 13:08:56 +0100 Von: Christoph Grein !topic Ruined paragraph !reference 2012 RM3.10.2(20) !from Christoph Grein 16-02-19 !discussion This paragraph is a bullet with an incomplete sentence. This is the previous version: For determining whether one level is statically deeper than another when within a generic package body, the generic package is presumed to be instantiated at the same level as where it was declared; run-time checks are needed in the case of more deeply nested instantiations. This is the new content: or generic function F It looks like an error - there is no reason to insert "generic function" in this paragraph - and also no /4 indication. *************************************************************** From: Randy Brukardt Sent: Thursday, March 24, 2016 11:37 PM > I resend this since I've never received a reply from the list, so I suspect the mail was lost somehow. I didn't think that it needed a reply. > Oh, now I see: the paragraph (20) is erroneously present. > When removed, the text is correct again. Right, just a chunk of floating junk. I'd guess that I cached a copy of a change block while I was inserting changes, and forgot to get rid of it when done (that happens periodically, I just usually see it before anything gets issued). The way the formatter works, anything at all gets a paragraph number. [I've seen a single square bracket with a paragraph number.] Since it only appears in the consolidated RM and AARM (but not the Ada 2012 Standard or Corrigendum), no formal action is needed. I repaired the source files and regenerated the HTML (which is easy) - which is why the error has magically disappeared from the online HTML. Regenerating the PDFs takes 4-6 hours (each needs a set of hand-repairs, and the only software that can make the PDF without crashing is on a very slow ancient machine -- and there is 7 different PDF files). So I thought I'd wait until some time had passed for any other errors to be reported. We have a tool that compares RM and Corrigendum text, but it only compares paragraphs that are supposed to have been changed. So it can't find extra junk (nor can it find paragraphs left out of the Corrigendum, another annoyance). Still is a lot better than nothing. P.S. Was this reply long enough? ;-) *************************************************************** From: Christoph Grein Sent: Friday, March 25, 2016 9:30 AM > P.S. Was this reply long enough? ;-) Oh sure, by Jove! (I meant however the automatic list reply which I received this time.) *************************************************************** !topic Undeleted deleted paragraph !reference Ada 2012 TC1 RM 3.3.1(19/2) !from Christoph Grein 16-07-15 !discussion In the Adobe Acrobat (.pdf) with changes from Ada 95 highlighted version, the para indicated above (on page 66) is not crossed out. The online HTML version (without highlighted changes) is OK. I haven't checked the other versions. *************************************************************** From: Randy Brukardt Sent: Thursday, July 21, 2016 6:05 PM Must be a tools bug. It appears in that version, and *only* that version, going back at least to the Ada 2005 RM. (All of the other RM formats and all of the AARM formats I checked are OK.) At least that is always an unofficial version; the critical version is RM-Final, and it is OK. Until it can be fixed, I suggest crossing the paragraph out with a pen on your printed copy, and using a different electronic version. *************************************************************** Editor's note (August 31, 2016): All of the items above this marker have been included in the working version of the AARM. ****************************************************************