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=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,610e53a911ec64b3
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1995-03-27 02:35:09 PST
Path: 
 nntp.gmd.de!news.rwth-aachen.de!news.rhrz.uni-bonn.de!news.uni-stuttgart.de!rz.uni-karlsruhe.de!xlink.net!howland.reston.ans.net!news2.near.net!news3.near.net!noc.near.net!eisner!kilgallen
From: kilgallen@eisner.decus.org (Larry Kilgallen, LJK Software)
Newsgroups: comp.lang.ada
Subject: Re: Importing C Structures
Message-ID: <1995Mar26.081652.9489@eisner>
Date: 26 Mar 95 08:16:52 -0500
References: <3kr4q3$jd9@newsflash.concordia.ca>  <D5zqB9.5F8@thomsoft.com>
Organization: DECUServe
Date: 1995-03-26T08:16:52-05:00
List-Id: <comp.lang.ada>

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;
> 
> The reason this is erroneous is that the compiler may not be aware that
> X and Y are really the same object (X may be declared in a different
> compilation unit, or the overlaid object might be something more
> complex than a simple object, say a dynamically indexed array element).
> The compiler is free to keep the value of X in a register, optimize out
> dead assignments, etc., so the apparent values of X and Y won't track

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?