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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,cef1e23795181e0c
X-Google-Attributes: gid103376,public
From: Samuel Mize <smize@imagin.net>
Subject: Re: Alternate to Unchecked_Conversion - Portable?
Date: 1999/02/22
Message-ID: <7aru71$iu6@news3.newsguy.com>#1/1
X-Deja-AN: 447134557
References: <36d05e39.0@news.pacifier.com> <7aqe04$uhl$1@nnrp1.dejanews.com>
Organization: ImagiNet Communications, Ltd.
User-Agent: tin/pre-1.4-981002 ("Phobia") (UNIX) (AIX/3-2)
Newsgroups: comp.lang.ada
Date: 1999-02-22T00:00:00+00:00
List-Id: <comp.lang.ada>

Just a couple of further points, I'm not disagreeing with Robert.

robert_dewar@my-dejanews.com wrote:
> In article <36d05e39.0@news.pacifier.com>,
>   "Steve Doiel" <nospam_steved@pacifier.com> wrote:
>> I discovered a technique for performing a similar
>> function to Unchecked_Conversion.  Locating two data
>> structures at the same address by defining the first
>> normally and then using an address clause to locate the
>> second at the same address as the first (as shown in the
>> following sample):
>>
>> My question is: is this portable?
> 
> Answer: this technique is standard and well known in Ada
> 95, though it was always wrong (erroneous) in Ada 83. It
> is definitely NOT portable, and in particular, and
> optimizer may get confused by the implicit aliasing, and
> you cannot complain if it does!

There are some architectures on which it's not even meaningful.
For instance, I don't expect this would be useful on a LISP
machine.

It does work on most compilers, especially if you use pragma
Volatile.

<language sniping on>

This seems to be the definition that is used by some advocates
of a language that shall remain nameless (but its initial is C).
Since several compilers support feature X, it's a "standard,
portable" idiom in that language.

<language sniping off>

And, in all fairness, that's sometimes a useful way to look at
such questions.


> It is usually just as simple (from a reader's point of
> view, and I sure hope that this is what you mean by simple)
> to use unchecked conversion of pointers, and much better
> defined, and likely to be more portable.

But be careful.  For example, if the pointed-at object is an
array of an unconstrained type, the access object is likely
to be TWO pointers: one to a "dope vector," and one to the
array data itself.  As another example, an access to an
object from a storage pool may not be a pointer at all, but
an offset address into the pool.  Robert knows all this, of
course, and his statement is a generalization -- all of which
have exceptions.

My point is that, if you're trying to look at one piece of
memory with two mappings, you have to know what this specific
specific compiler does on this specific architecture, in this
specific case.

It is an *extremely* non-portable idiom in the general case,
although specific instances may be fairly portable (in the
informal sense of the word).  I believe that this statement
is true in both C and Ada, although the C culture relies on
this particular idiom much more commonly.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam