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-28 11:45:58 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!Germany.EU.net!howland.reston.ans.net!news.sprintlink.net!crash!telesoft!kst From: kst@thomsoft.com (Keith Thompson) Subject: Re: Importing C Structures X-Nntp-Posting-Host: pulsar Message-ID: Originator: kst@pulsar Sender: news@thomsoft.com (USENET News Admin @flash) Organization: Thomson Software Products, San Diego, CA, USA References: <3kr4q3$jd9@newsflash.concordia.ca> <1995Mar26.081652.9489@eisner> Date: Mon, 27 Mar 1995 23:39:15 GMT Date: 1995-03-27T23:39:15+00:00 List-Id: In <1995Mar26.081652.9489@eisner> kilgallen@eisner.decus.org (Larry Kilgallen, LJK Software) writes: > In article , 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'.