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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,74b55538385b7366 X-Google-Attributes: gid103376,public From: Florian Weimer Subject: Re: Which is right here - GNAT or OA ? Date: 1999/05/30 Message-ID: #1/1 X-Deja-AN: 483845200 References: <928083159.436.79@news.remarQ.com> Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@cygnus.stuttgart.netsurf.de X-Trace: deneb.cygnus.stuttgart.netsurf.de 928093448 5692 192.168.0.1 (30 May 1999 19:44:08 GMT) Organization: Penguin on board Mime-Version: 1.0 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.1 (20 Minutes to Nikko) NNTP-Posting-Date: 30 May 1999 19:44:08 GMT Newsgroups: comp.lang.ada Date: 1999-05-30T19:44:08+00:00 List-Id: "Vladimir Olensky" writes: > RM Section 13.11.2 does not describe clearly and explicitly this case > so there is no wonder that the two best compiles behave differently. Well, actually it does (see RM 13.11.2(16)): | The execution of a call to an instance of Unchecked_Deallocation is | erroneous if the object was created other than by an allocator for an | access type whose pool is Name'Storage_Pool. So in fact, there's no contradiction, although the two compilers behave differently. I don't think the language designers could have specified anything but erroneous execution in this case. For example, it is very complicated to detect that the value of an Access attribute of an aliased record component is not a valid argument for a given instance of Ada.Unchecked_Deallocation if the record itself has been created by an allocator. Simple heuristics based on the machine address of the object in question clearly do not work here. Another but related thing surprises me---it's AARM 12.5.4(4.a): | If no _modifier applies to the formal, then the actual type may be | either a pool-specific or a general access-to-variable type. I can't imagine any reason why an access-to-variable type should be allowed as an actual parameter for a formal access type without an `all' modifier. If this was changed, an access-to-variable would not be allowed as a parameter in an instantiation of Ada.Unchecked_Deallocation, which seems quite reasonable to me. (I don't claim that the language definition inadequate here, I simply can't make sense out of it, which is very likely my own fault. ;)