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: 18 Aug 93 00:39:40 GMT
From: cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!cs.utexa
s.edu!swrinde!menudo.uh.edu!nuchat!leeweyr!bill@ucbvax.Berkeley.EDU  (Bill Lee)
Subject: Re: Data Overlays
Message-ID: <1993Aug18.003940.2208@leeweyr.sccsi.com>
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 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?
>


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.
Once I have a message in a Byte_Array, and once I know what kind
of message it is, I can then convert the message to an Ada record
which has the right structure for the message.

I've considered both methods above. Certainly, Unchecked_Conversion
is one alternative. But I have used another method which seems to
work, seems to be portable, and, moreover, SEEMS to be in line with
what the language designers intended. To wit:

Given an Ada type, Messages:

generic
  type Byte_Arrays is private;
function Extract_Message ( A_Message : in Byte_Arrays ) return Messages;

where the body looks like

function Extract_Message ( A_Message : in Byte_Arrays ) return Messages is
  Temp_Message : Messages;
  for Temp_Message use at A_Message'address;
begin
  return Temp_Message;
end Extract_Message;

In many cases, I have actually created a more "Ada-like" message
type, and I do far more than just return the C structure.

I like the "feel" of this method. It uses the representation
specification which allows a structure to be placed "at" an address.
If this usage is not what the language designers had in mind, then
what was the purpose of the rep spec?

Is there any inherent danger or "wrongness" in this technique? And
yes, I have read the "for the purpose of overlaying....erroneous"
section in the LRM. Is this overlaying? Is it erroneous?

Incidently, I use this same technique in bindings where I have to
deal with structures created in C. The C code malloc's the memory
and places structs in it, and then just passes back the C pointer.
I make the assumption (possibly in error in some cases) that a C
pointer and a System.Address are coincident. Then I can calculate
the address in the malloc'ed memory where a specific C structure
exists, and I can assign an Ada record "at" that address in order
to extract the information from it.

This technique evokes no complaints from the DEC compiler, and it
seems to work properly. We're running ULTRIX workstations.

Comments/observations/suggestions (hell, maybe even a flame or two
8-{) would be appreciated.

Regards,

Bill Lee

(Not at work, at home. We're so damned secure there that it's hard
to work!)

bill@leeweyr.sccsi.com