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,a9926825c099a467
X-Google-Attributes: gid103376,public
From: stt@houdini.camb.inmet.com (Tucker Taft)
Subject: Re: record rep on tagged record question
Date: 1997/10/01
Message-ID: <EHE64y.LA9.0.-s@inmet.camb.inmet.com>#1/1
X-Deja-AN: 277132261
Sender: news@inmet.camb.inmet.com (USENET news)
References: <60tq70$4p7@lotho.delphi.com>
X-Nntp-Posting-Host: houdini.camb.inmet.com
Organization: Intermetrics, Inc.
Newsgroups: comp.lang.ada
Date: 1997-10-01T00:00:00+00:00
List-Id: <comp.lang.ada>


tmoran@bix.com wrote:

: ...
:   This is intended as a 'confirming' record rep clause, since the
: compiler in question *seems* to do the expected thing, but it would be
: nice to be sure.  

One Ada 95 front end with which I am familiar (;-) places all un-rep-speced
fields after those with rep-clauses, making no attempt to use up
gaps left earlier in the record.  Until very recently, this applied
to the tag field as well, meaning that if you put a rep-clause on
a tagged type, the tag field ended up getting placed *after* all the
rep-claused fields.  Furthermore, there was a bug that if *all* the
fields were rep-claused (except the implicit "tag" field), then
it didn't leave any extra room at the end for the tag, and the tag 
got allocated off the end of the record (gack!).

Hence, a "confirming" rep clause on a tagged type definitely did
not have the desired effect of ensuring the layout was the same
as you would expect.

Upon seeing your example, we now special case the tag, and try to put it 
at offset 0 even in the presence of rep-clauses, if a gap is left there.
If there is no gap there, we still put the tag after the rep-claused
fields (but now we don't forget it when computing the record size!).
We still ignore other gaps left by rep-clauses when placing other
explicit non-rep-claused fields.   

I can't comment on what other Ada 95 front ends do...

: ... If 'Position could be used on a type, instead of just
: an object, I could make a compile time constraint error test - but it
: can't.  

You could perhaps do something like:

    package body XXX is
      ...
    begin
        if False then
             declare
                 Obj : My_Tagged_Type;
             begin
                 pragma Assert(Obj.My_Field'Position = DESIRED_POSITION);
             end;
        end if;
    end XXX;

This might give you a warning if the Assert is known false at compile-time.

I suppose another approach which might accomplish the goal is:

    package body XXX is
      ...
        Check_Obj : My_Tagged_Type;
        pragma Import(Ada, Check_Obj);
        for Check_Obj'Address use System.Null_Address;
        pragma Assert(Check_Obj.My_Field'Position = DESIRED_POSITION);
      ...
    end XXX;

FWIW, one reason 'Position can't be used on a type is that in some cases,
the 'Position of a field may depend on the value of discriminants.
Another reason is that "<type>.<fieldname>" is not normally a legal 
construct, meaning that <type>.<fieldname>'Position would
require a whole lot of special handling in the front end.  
Be that as it may, I admit to often wishing 'Position 
(and 'First/Last_Bit) could be used on types.  

One possibility might be to define an attribute, say Field_Position,
that worked on constrained (to avoid the discriminant problem) record 
subtypes as follows:

    <constrained_subtype>'Field_Position("<fieldname>") 

where the string "<fieldname>" is required to be static, and match some
visible field of the <constrained_subtype>.

: ... RM 13.5.1(21) certainly leads me to believe this rep clause
: should be legal.

The rep-clause is certainly legal.  However, as indicated above,
there is no guarantee that it only "confirms" the desired layout,
but instead may perturb it in undesirable (and in this case,
bug-infested) ways.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA