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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!ulysses!allegra!mit-eddie!husc6!cca!mirror!ishmael!inmet!ron
From: ron@inmet.UUCP
Newsgroups: comp.lang.ada
Subject: Re: A Bug in VAX Ada (ACCVIO)
Message-ID: <124000008@inmet>
Date: 14 Jan 88 16:51:00 GMT
References: <1@<1988>
Nf-ID: #R:<1988:-100:inmet:124000008:000:975
Nf-From: inmet.UUCP!ron    Jan 14 11:51:00 1988
Posted: Thu Jan 14 11:51:00 1988
List-Id: <comp.lang.ada>


This program is definitely legal.  One of the holes in the analysis leading
to the incorrect "program is erroneous" conclusion is the assertion that B, a
string typed object, "designates" the string object.  In fact, "designates"
is a technical term applicable only to access types and tasks; the assignment
involved in B's elaboration simply sets the "value" of B.  Although the value
assigned happens to be the value designated by A, this is irrelevent after
the assignment.

Have you tried compiling it with the /nooptimize switch?  I bet that you'll
get more appropriate behavior. 

Over the last few years, I've encountered various bugs with the VAX Ada
compiler's handling of access types.  The simplest (and my personal
favorite) example is that Unchecked_Deallocation(null) raises
Program_Error.  This is my favorite because the only concrete thing
that the LRM has to say about Unchecked_Deallocation is that after any
call to Unchecked_Deallocation(x), x is null.