Re: Importing C Structures

[kst@thomsoft.com (Keith Thompson)]

In <1995Mar26.081652.9489@eisner> kilgallen@eisner.decus.org (Larry Kilgallen, LJK Software) writes:
> In article <D5zqB9.5F8@thomsoft.com>, kst@thomsoft.com (Keith Thompson) writes:
> > Here's an example of an erroneous use of address clauses in Ada 83:
> > 
> >     X : Integer;
> >     ...
> >     Y : Integer;
> >     for Y use at X'Address;

[...]

> For an address representation clause, which might be used to access hardware,
> optimizing out dead assignments seems quite inappropriate.  Is there no
> Ada83 method of avoiding such an optimization for such objects?

I certainly agree that optimizing out dead assignments for an object
to which an address clause applies is inappropriate.  I suspect most or
all Ada 83 compilers treat such objects specially (but consult your
compiler documentation to be sure).  In the example, accesses to Y
are probably safe from such optimizations.

The problem is that access to X may not be safe.  If you write a value
to X (which *doesn't* have an address clause) and then try to read it
through Y, you may not get the results you expect, since the generated
code might not bother to store the value at X's address.  This is an
example of a general problem with aliasing; I think you can run into
the same kind of problems with subprogram parameters passed by reference.

It is possible for a compiler to do the analysis needed to mark any
*potentially* aliased objects as volatile, avoiding this problem, but
I don't know how many actual compilers do so.  Any variable visible to
other compilation units can be aliased in this way.  (There presumably
won't be very many such objects in well-designed code.)

To summarize, if you alias two declared objects by using an address
clause, it's likely that they'll behave as you'd expect, but it's usually
far better to use other methods.  If you want to alias an object with
the same type, use a renames declaration; if you need a different type,
use Unchecked_Conversion (which explicitly accesses the aliased object).

-- 
Keith Thompson (The_Other_Keith)  kst@thomsoft.com (kst@alsys.com still works)
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
That's Keith Thompson *with* a 'p', Thomson Software Products *without* a 'p'.