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,e08ffaff681705c
X-Google-Attributes: gid103376,public
From: tmoran@bix.com
Subject: Re: access aliased obstacle
Date: 1996/07/09
Message-ID: <4rsmn6$hvc@news1.delphi.com>#1/1
X-Deja-AN: 167317629
organization: Delphi Internet Services Corporation
newsgroups: comp.lang.ada
Date: 1996-07-09T00:00:00+00:00
List-Id: <comp.lang.ada>


>Are you trying to interface a C union (array of)? If it's the case,
>I think the use of Unchecked_Union may be of interest (and I believe
>it will be portable between Ada 95 implementation).
  I think of a C union as essentially a variant record with the
discriminant outside the record (in some other variable entirely).
C probably does think of this as a union, although it fits an Ada
discriminated record perfectly.  What is this 'Unchecked_Union'?
I don't see it in my LRM.

>non-limited types.  So, just make type Elements limited (i.e. change "is
>record" to "is limited record") and it will be OK.  There is some
  This is a glue package between Ada and a set of OS routines.  It would
be inconvenient, and hard to explain to users, why these discriminated
records ought to be 'limited'.  So right now I do an Unchecked_Conversion
to a local array of undiscriminated, and thus aliasable, records.  Since
it's in an OS call, and we're not talking enormous arrays, the marginal
performance hit is bearable.  But it sure isn't pretty.