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=-0.9 required=3.0 tests=BAYES_00,FROM_ADDR_WS
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 19 Aug 93 13:16:24 GMT
From: cs.utexas.edu!mars.tsd.arlut.utexas.edu!gardner@uunet.uu.net  (Don Gardne
r)
Subject: Re: Data Overlays
Message-ID: <1993Aug19.131624.2392@titan.tsd.arlut.utexas.edu>
List-Id: <comp.lang.ada>

jcrigler@theopolis.orl.mmc.com (Jim Crigler) writes:

>Bill Lee (bill@leeweyr.sccsi.com) wrote:
>: In article <1993Aug13.124835.18422@iplmail.orl.mmc.com>
>: rgilbert@orl.mmc.com writes:
>: >
>: >Many times I have wanted to create two different types to look at the
>: >same object.
>:
>: O.k., Here's my problem:

>: I have a system which receives "messages" from a number of other
>: systems. The messages come via POSIX queues. On any one queue, I
>: can receive a number of different messages, mostly with record
>: structures defined by the C code where the message originated.

>: I do not know a priori what the next message will be. I have to
>: "receive" the message into a Byte_Array. Once I have the message,
>: I can access a standard header and extract a message identifier,
>: which then tells me what kind of message I've just received.

>What about a variant record?  Language Lawyer question (my LRM is at
>home):  are rep. specs allowed on variant records?  If so (and if you
>have a single tag at any level that determines what the message is at
>that level), use an address clause to store the data on the Byte_Array,
>then use the variant to figure out what you've got.

I have had some difficulty using representation specifications
in code that is supposed to be portable.  In particular, in an
attempt to port a large amount of communication protocol code
from a 68030 platform to a SPARC, we found that a representation
clause caused a "bus error" during elaboration because 16-bit
integers were mapped to odd addresses in records defining
messages.  Unfortunately, the types that have this problem are
widely used throughout the code and are controlled by someone
else.  When they modify the code we have to port the
modification.

IMHO, the problem boils down to the fact that my preference is
to structure my code into 3 steps which are as completely
separated as possible.  These steps are:

    1.  Convert the input from some external representation to a
        native/natural representation for the problem.
    2.  Process the data.
    3.  Convert the output from its native/natural representation
        to some external representation.

Representation clauses violate this separation because they
cause assignment statements throughout the processing step to
also become conversions.

The realization that these steps are being followed also helps
one structure the code and types such that when data are
processed in several phases, the representation used in each
phase is the natural representation for that phase and can be
changed without affecting the other phases.  Only the conversion
code needs to be modified.