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,FREEMAIL_FROM, 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: "Vladimir Olensky" Subject: Re: Which is right here - GNAT or OA ? Date: 1999/05/31 Message-ID: <928174549.336.98@news.remarQ.com>#1/1 X-Deja-AN: 484153496 References: <928083159.436.79@news.remarQ.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Complaints-To: newsabuse@remarQ.com X-Trace: 928174549.336.98 K3TLTKYJOA5C9C7F8C qube-02.us-ca.remarq.com Organization: Posted via RemarQ Communities, Inc. NNTP-Posting-Date: Mon, 31 May 1999 18:15:49 GMT Newsgroups: comp.lang.ada Date: 1999-05-31T00:00:00+00:00 List-Id: Florian Weimer wrote in message ... >"Vladimir Olensky" writes: > >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. As a matter of fact this is amazingly simple. If I can do this check at a run time myself why RTS can not do the same ? The cost of this is one additional hidden field in the type representation which is set to needed value during object creation. Soon I demonstrate this simple technique in set of "talking" examples that are almost ready to be posted to AdaPower. The same thing could be done by the compiler itself. There even will be no need to have additional public run time attributes. Compiler or allocator sets this field during object creation and RTS can check this field and do what needed depending on value of this field upon object deallocation request. This could be very handy. > >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. ;) Yes, very interesting, I agree, it does not go all along the line with Ada strong type checking. In some circumstances it may cause the same result that was demonstrated in my small demo. Regards, Vladimir Olensky