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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: for X'Address use - and Volatile Date: Wed, 31 Aug 2016 14:36:24 -0500 Organization: JSA Research & Innovation Message-ID: References: <7595494c-3398-4fd9-ab4b-80a79383ae33@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1472672174 31138 24.196.82.226 (31 Aug 2016 19:36:14 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 31 Aug 2016 19:36:14 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:31662 Date: 2016-08-31T14:36:24-05:00 List-Id: "Maciej Sobczak" wrote in message news:7595494c-3398-4fd9-ab4b-80a79383ae33@googlegroups.com... Hi, >Consider: >X : Integer; >Y : Integer; >for Y'Address use X'Address; > >The above is a simple overlay, typically used for under-the-table type >conversions. Ada does not now, nor ever has, officially supported overlays. Such code might work on a particular implementation, but it's not portable (even to another version of the same compiler). Indeed, address clauses ought to be avoided for all but their intended purpose (mapping to hardware registers); for other purposes, better solutions exist (Unchecked_Conversion, Address_to_Access_Conversions, etc.) In addition, since you didn't declare these objects aliased, the compiler is allowed to optimize them completely away. >AARM 13.3 says: > >"If the Address of an object is specified [...], then the implementation >should not perform optimizations based on >assumptions of no aliases." > >Interestingly, in the above example there are two objects involved in the >overlay, yet only one (Y) >is affected by this rule (becaue Address is *specified* only for Y, not for >X). Let's assume that >this is an omission It's not. You ignored the important rule, 13.3(13/3): If an Address is specified, it is the programmer's responsibility to ensure that the address is valid and appropriate for the entity and its use; otherwise, program execution is erroneous. The associated AARM note says that "Appropriate for the entity and its use" covers cases like "addresses which would force objects that are supposed to be independently addressable to not be". Since X and Y are independently addressable and there is no way to avoid that, this case *always* will cause erroneous execution. Compilers (obviously) don't have to protect against that, so any optimization on X is allowed. Indeed, since X isn't aliased, it's not even required that X'Address is meaningful (it could be in a machine register). These things *might* work on a particular implementation, but no guarantees. The correct way to do this is something like: package A2A is new System.Address_to_Access_Conversions (Integer); X : aliased Integer; Y : A2A.Object_Pointer := A2A.To_Pointer (X'Addresss); or better still, avoid Address altogther: type Acc_Int is access all Integer; X : aliased Integer; Y : Acc_Int := X'Access; -- Or 'Unchecked_Access if accessibility is an issue. (You need the former if the types are different, the latter if not. But Ada doesn't really allow the case with the types being different to be portable in any case - Unchecked_Conversion is needed, and even that isn't certain to be portable depending on the types involved.) Randy. P.S. Yes, you hit two of my pet peeves about the way some people use Ada. Most compilers (but not Janus/Ada 95) try to support the overlay case because it was common in Ada 83 code -- both of the better alternatives didn't exist until Ada 95. Similarly with the use of Aliased on any stand-alone object that you're planning to take the 'Address of. Trying to support these things makes Ada optimization many times more complex and substantially less effective than it otherwise could be. I suppose GNAT gets away with it since C has these issues many times worse and thus there already is support for that in the GCC backend. People not using a C backend have no such (dis?)advantage. Grrrrr.