access aliased obstacle

access aliased obstacle

[tmoran]

To pass a data structure to an OS routine I tried

  type elements(discriminant: enumeration_type:=normal_value) is record
    case discriminant is
    ...
  end record;
  for elements'size use 64;  -- size does not vary

  type list_of_elements is array(1 .. 17) of aliased elements;

but one of my Ada 95 compilers objected to aliasing unless I make a
subtype with a specific discriminant value, which defeats the purpose.
The LRM appears to me to agree with this compiler.  The only obvious
possibility is unchecked_conversion.  What is the 'right' way?

Re: access aliased obstacle

[Robert Dewar]

tmoran said

"but one of my Ada 95 compilers objected to aliasing unless I make a
subtype with a specific discriminant value, which defeats the purpose.
The LRM appears to me to agree with this compiler.  The only obvious
possibility is unchecked_conversion.  What is the 'right' way?"

The use of unchecked conversion here is not at all obvious to me. We
would have to look at the detailed code you propose, but the restriction
in the RM makes good sense, and I would guess that your uncchecked
conversion approach simply will not work in some implementations.

Re: access aliased obstacle

[Laurent Guerby]

> To pass a data structure to an OS routine I tried
> 
>   type elements(discriminant: enumeration_type:=normal_value) is record
>     case discriminant is
>     ...
>   end record;
>   for elements'size use 64;  -- size does not vary
> 
>   type list_of_elements is array(1 .. 17) of aliased elements;
[...]

   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).

   An array of general access may also be closer to C here.

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: access aliased obstacle

[Robert A Duff]

(Mailed and posted.)

In article <4rfig3$l5d@news1.delphi.com>,  <wtmoran@bix.com> wrote:
>To pass a data structure to an OS routine I tried
>
>  type elements(discriminant: enumeration_type:=normal_value) is record
>    case discriminant is
>    ...
>  end record;
>  for elements'size use 64;  -- size does not vary
>
>  type list_of_elements is array(1 .. 17) of aliased elements;
>
>but one of my Ada 95 compilers objected to aliasing unless I make a
>subtype with a specific discriminant value, which defeats the purpose.
>The LRM appears to me to agree with this compiler.  The only obvious
>possibility is unchecked_conversion.  What is the 'right' way?

The restriction you're talking about is in 3.6(11).  It applies only to
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
discussion of the rule in the AARM starting at 3.6(11.a).

- Bob

Re: access aliased obstacle

[tmoran]

>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.

Re: access aliased obstacle

[Laurent Guerby]

>>   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.

   A discriminated record isn't a C union type, because the
discriminant is stored in the record in Ada (accessible for reading),
and run-time checks are made on the discriminant when you access
variant parts. The pragma Unchecked_Union makes a simple Ada
discriminated record type match exactly a C union (discriminant not
stored, no checks). It is not in the RM, but all vendors agreed to
implement it. It is documented in the GNAT file "features" I think (or
gnatinfo.txt).

   I still assume you're interfacing a C array of union, but I'm not
sure, and cannot be more accurate without the code (C and what you
want in Ada).

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: access aliased obstacle

[Robert Dewar]

Laurent said

"   A discriminated record isn't a C union type, because the
discriminant is stored in the record in Ada (accessible for reading),
and run-time checks are made on the discriminant when you access
variant parts. The pragma Unchecked_Union makes a simple Ada
discriminated record type match exactly a C union (discriminant not
stored, no checks). It is not in the RM, but all vendors agreed to
implement it. It is documented in the GNAT file "features" I think (or
gnatinfo.txt)."

Not quite right, there is no reason why a discriminant in a variant record
should be stored "in the record" in Ada, that is just a (common)
implementation choice. In fact if you are using sub types extensively
it is attractive to choose an alternative representation where the
discriminants are stored separately,

However, the point about discriminant checks is right of course (although
if one had an implementation which stored discriminants separately, you
would get almost what you wanted simply by suppressing these checks).

Re: access aliased obstacle

[Laurent Guerby]

Robert> Not quite right, there is no reason why a discriminant in a
Robert> variant record should be stored "in the record" in Ada, that
Robert> is just a (common) implementation choice. In fact if you are
Robert> using sub types extensively it is attractive to choose an
Robert> alternative representation where the discriminants are stored
Robert> separately,

   The idea is that there are stored somewhere, "in the record" is an
unfortunate wording ;-). BTW, is there any compiler that use the
alternative you proposed ? How to get the following right without
storing "in the record"?

type T (D : boolean) is null record;

function F return T is
begin 
   return T'(True);
end F;

begin
   if F.D then ...
end;

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: access aliased obstacle

[Robert Dewar]

Laurent said

"   The idea is that there are stored somewhere, "in the record" is an
unfortunate wording ;-). BTW, is there any compiler that use the
alternative you proposed ? How to get the following right without
storing "in the record"?"

I don't think any compilers do this, but it is perfectly viable to treat
discriminants like subscripts for arrays, which certainly need not be
stored with the arrays (think of the fat pointer implemenation in
GNAT for arrays, it could easily adapt to variant records, with 
separate pointers to the discriminants and data). 

When we were designing the info systems annex, we considered using
a variant record design for decimal numbers with the precision being
a diiscriminant, but that is only viable if you do this separate
allocation, and we did not feel that would be easy for compilers
to do!

Re: access aliased obstacle

[Robert A Duff]

In article <dewar.836958957@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
[stuff about storing discriminants separately]

If you do that, then in some cases, you can avoid storing the
discriminants altogether.  If you have a variable
X: T(Discrim => static-expression), then there's no need to store
X.Discrim anywhere.  Of course if X is ever passed to an unconstrained
formal parameter, the discriminant value has to be materialized at that
point.  And aliased variables need to have discriminants attached to
them, or accessible in some way.

Discriminants are really quite similar to array bounds.

- Bob

Re: access aliased obstacle

[Robert Dewar]

tmoran says

"  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."

That is precisely the view that Unchecked_Union takes, it allows the
use of a variant record with no variant field stored, so it can exactly
map to a C union.

This pragma is implemented with consistent semantics in both the
Intermetrics compilers and in GNAT, and is used in the Win32 bindings.
For details, see the file features included with the GNAT documentation,
which has a full description of this pragma. You will definitely not
find it in the RM for the simple reason that it is not there. Tecnhnically
this is an imlementation defined attribute, but in practice it is one on
which there is agreement that it will be implemented consistently across
compilers.