From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 17 Aug 93 15:16:00 GMT
From: sampson@cod.nosc.mil  (Charles H. Sampson)
Subject: Re: Data Overlays
Message-ID: <1993Aug17.151600.18557@nosc.mil>
List-Id: <comp.lang.ada>

In article <1993Aug13.124835.18422@iplmail.orl.mmc.com> rgilbert@orl.mmc.com wr
ites:
>
>Many times I have wanted to create two different types to look at the
>same object.  An example might be a record structure which is to be
>output via some DMA device which expects the data to look like an 
>array of bytes.  Anyway I've come up with two different methods to
>implement this.
>
>Method 1 :  Use an access type of one of the types and assign the address
>            (using unchecked conversion) of the object declare of the
>            other type.
>
> [Example deleted]
>
>Method 2:  Just use a representation clause to map one of the objects to the
>           address of the other.
>
>      X : SAMPLE_REC_TYPE;
>      Y : BYTE_ARRAY_TYPE;
>      for Y use at X'address;
>
>   This seems to be much more straight forward and makes no assumptions about
>   the implementation.  But when this method is used a compiler (Telesoft)
>   warning is issued to the affect that the representation clause should not
>   be used to produce overlayed data?
>
>Question:  Which of the above methods is prefered?  Is there a better way?

     If you truly have to look at the data structure from two different
aspects, use Unchecked_conversion.  That's what it's there for.  There
seems to be an opinion circulating that Unchecked_conversion is a feature
of Ada that should never be used.  Not so.  It's in the language precisely
for the kind of situation described.  On the other hand, it should not be
used for some cutesy trick whose effect can be easily achieved in some
other, more portable, fashion.

     There are some portability considerations, because the exact rules on
which types can participate in unchecked conversions are implementation
dependent.  In my experience, compilers allow unchecked conversions between
most types of the same size.  I'm sure there are exceptions to my experience.

     I don't see any advantage in using Unchecked_conversion on the access
types instead of the record structures themselves.  The indirection adds a
level of obscurity, whereas a straightforward use of Unchecked_conversion
says, "Hey, look.  I'm approaching this bucket of bits from a different
point of view."

     As for creating an overlay by using an address clause, here's the kind
of problem you could get into.  Consider the following very simplified
example:

          X : Integer;
          Y : Integer:
          FOR X USE AT Y'Address;

          X := 1;
          ...
          IF Y = 1 THEN ...

It might be that your compiler, using standard code generation techniques,
is using a delayed store on the value of X, which means basically that the
1 is held in a register for a period of time rather than being immediately
placed into the memory location of X.  As a result, Y does not have the
expected value when the IF statement is executed.  Since the overlaying has
created an erroneous program, the compiler writers are not obligated to
take it into account in their code generation schemes, which is a blessing
if you've every had to consider all the side effects of overlaying.  As a
matter of fact, since this program is erroneous, the compiler writers are
legally allowed to do bizarre things, such as erasing your disk, but that's
another story.

                              Charlie