!standard 5.1(16) 13-01-14 AC95-00243/00 !standard 6.3.1(8) !class confirmation 13-01-14 !status received no action 13-01-14 !status received 12-10-12 !subject Possible errors in the RM examples !summary !appendix !topic GNAT compilation error !reference 5.1_16b !from Pascal Pignard 12-11-08 !discussion If I've well coded the example 5.1_16b as the following: procedure Record_Result (R:Integer) is null; task Compute is entry Ent(I : out Integer; J : in Integer); end; task body Compute is Sum : Integer := 0; -- Compute.Sum begin Outer: -- Compute.Outer for I in 1..10 loop -- Compute.Outer.I Blk: -- Compute.Blk declare Sum : Integer := 0; -- Compute.Blk.Sum begin accept Ent(I : out Integer; J : in Integer) do -- Compute.Ent.I, Compute.Ent.J Compute.Ent.I := Compute.Outer.I; -- invalid prefix in selected component "I" Inner: -- Compute.Blk.Inner for J in 1..10 loop -- Compute.Blk.Inner.J Sum := Sum + Compute.Blk.Inner.J * Compute.Ent.J; -- invalid prefix in selected component "J" end loop Inner; end Ent; Compute.Sum := Compute.Sum + Compute.Blk.Sum; end Blk; end loop Outer; Record_Result(Sum); end Compute; GNAT issued 2 errors on I and J from Compute.Ent: invalid prefix in selected component "I" invalid prefix in selected component "J" Maybe a GNAT compilation error as it is ok with a procedure instead of an entry? Could any body confirm? *************************************************************** From: Edmond Schonberg Sent: Thursday, November 8, 2012 5:20 PM This appears to be a glitch in GNAT, thanks for the report. [Ergo, it is not a problem with the example - Editor.] *************************************************************** !topic Missing initial value !reference 6.3.1 Conformance Rules !from Pascal Pignard 12-11-18 !discussion In the example section 8.a.1/1 the type Formal is a generic parameter of G, its value should be also given as generic parameter: Especially, this value is required for X: 6.3.1 Conformance Rules <...> 8.a.1/1 Reason: Consider: 8.a.2/1 package P is type Root is tagged null record; procedure Proc(X: Root); end P; 8.a.3/1 generic type Formal(<>) is new Root with private; package G is ... end G; 8.a.4/1 package body G is ... X: Formal := ...; ... Proc(X); -- This is a dispatching call in Instance, because -- the actual type for Formal is class-wide. ... -- Proc'Access would be illegal here, because it is of -- convention Intrinsic, by the above rule. end G; 8.a.5/1 type Actual is new Root with ...; procedure Proc(X: Actual); package Instance is new G(Formal => Actual'Class); -- It is legal to pass in a class-wide actual, because Formal -- has unknown discriminants. My proposal: generic type Formal(<>) is new Root with private; Value : Formal; --@@ package G is -- ... end G; package body G is -- ... X: Formal := Value; --@@ -- ... package Instance is new G(Formal => Actual'Class, Value => Actual'(Root with null record)); --@@ One more thing, GNAT don't issue error on Proc'Access: -- Proc'Access would be illegal here Test(Proc'Access); --@@ no GNAT error ? It is in contradiction with the comment, isn't it? *************************************************************** From: Randy Brukardt Sent: Tuesday, November 20, 2012 12:14 AM > In the example section 8.a.1/1 the type Formal is a generic parameter > of G, its value should be also given as generic parameter: Why? The source of the initial value is not important to the example. There are a number of ways that X could be initialized, and using for a formal object is probably the least likely. (Besides, a real program probably would be using a formal parameter of type Formal rather than a stand-alone object.) Moreover, this is not a complete example (as should be obvious by the "..." in it). Adding stuff to it that is not related to the point of the example just would make it harder to understand. ... > One more thing, GNAT don't issue error on Proc'Access: > -- Proc'Access would be illegal here > Test(Proc'Access); --@@ no GNAT error ? > It is in contradiction with the comment, isn't it? GNAT is just one implementation of Ada, and what it does on a particular program is not particularly interesting. [Here, I'm sure AdaCore cares - Editor.] It probably has plenty of bugs in the sorts of corner cases that are described in AARM notes. What would be useful is creating and submitting good ACATS-style tests for cases that you find important that some implementation is getting wrong. Some suggestions for creating such tests can be found in Guidelines for Test Development in the ACATS documentation (see http://www.ada-auth.org/acats-files/3.0/docs/UG-E.HTM). But this is the wrong mailing list for that (send/discuss ACATS tests on ACAA@ada-auth.org). ***************************************************************