From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,de8112bdf65b223b X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.66.72.98 with SMTP id c2mr944162pav.28.1360469025451; Sat, 09 Feb 2013 20:03:45 -0800 (PST) Path: mj10ni1100pbb.1!nntp.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Inheritance of representation aspects Date: Mon, 04 Feb 2013 18:23:33 +0000 Organization: A noiseless patient Spider Message-ID: References: Mime-Version: 1.0 Injection-Info: mx05.eternal-september.org; posting-host="0a6ca0935c728e617c1a2d4bdcfc6a33"; logging-data="17357"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+aQ3IE4dPz8FYRtaWKCdrsk6J45MJ83A4=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (darwin) Cancel-Lock: sha1:0GupIRwfcfdcmGg1zEnn7ltoB1Y= sha1:8F6G1hp/iwoOH3mPYVkexgDK6fs= X-Received-Bytes: 4166 Content-Type: text/plain Date: 2013-02-04T18:23:33+00:00 List-Id: Adam Beneschan writes: > On Sunday, February 3, 2013 8:27:20 AM UTC-8, Simon Wright wrote: >> A question on Stack Overflow[1] asks about deriving from an unchecked >> union. The questioner thinks that a derived type should also be >> an unchecked union, but GNAT doesn't. >> A demo is >> >> package Union is >> type Access_Kind is (Named, Indexed); >> type Array_Type is array (0 .. 1) of Integer; >> >> type Base (Kind : Access_Kind := Access_Kind'First) is record >> case Kind is >> when Named => >> X, Y : Integer; >> when Indexed => >> S : Array_Type; >> end case; >> end record with >> Unchecked_Union => True, >> Convention => C_Pass_By_Copy; >> >> -- A primitive operation, freezes Base. >> procedure P (R : Base) is null; >> >> -- Derived types should inherit both representation aspects, so >> -- both these aspects should be confirming >> type Derived_1 is new Base with Unchecked_Union => True; >> type Derived_2 is new Base with Convention => C_Pass_By_Copy; >> >> -- This should fail (ARM 13.1(10)). >> type Derived_3 is new Base with Unchecked_Union => False; >> >> end Union; >> >> Both Unchecked_Union and C_Pass_By_Copy are representation aspects, and >> should therefore be inherited (I've given links at my SO answer[2]). So >> the aspects specified for Derived_1 and Derived_2 should both be >> confirming and therefore OK (?), while the aspect for Derived_3 should >> be illegal by ARM 13.1(10). >> >> With GNAT GPL 2012 and GCC 4.8.0 (r195682), Derived_1 and Derived_2 fail >> (representation item appears too late) and Derived_3 doesn't raise an >> error. >> >> With GNAT GPL 2012, if I comment out Derived_1 and Derived_2, the >> compilation is successful (with 4.8.0 I get a bug box, which is a >> separate issue). >> >> Am I correct that these aspects should be inherited? > > You're right that they should be inherited (13.1(15)), and that the > declaration of Derived_3 would be illegal. > > I'm not clear that Derived_1 and Derived_2 are legal, however. The > aspect clauses are confirming, but there's no blanket rule that > confirming aspect clauses are always legal. The rule in 13.1(10) says > > "For an untagged derived type, it is illegal to specify a type-related > representation aspect if the parent type is a by-reference type, or > has any user-defined primitive subprograms." > > So it's illegal, period. There is no exception here for confirming > aspect clauses. Still, it's be nice for it to be legal (perhaps 13.1(18.2) could be amended to say that a confirming aspect clause isn't "really" a specification?! Simpler if (10) just said that "For an untagged derived type, it is illegal to specify a *non-confirming* type-related representation aspect if the parent type is a by-reference type, or has any user-defined primitive subprograms."