Re: for X'Address use - and Volatile

["Randy Brukardt" <randy@rrsoftware.com>]

"Maciej Sobczak" <see.my.homepage@gmail.com> 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.