Version 1.2 of ais/ai-00291.txt

Unformatted version of ais/ai-00291.txt version 1.2
Other versions for file ais/ai-00291.txt

!standard 4.09 (38)          02-04-19 AI95-00291/01
!class binding interpretation 02-03-26
!status received 02-03-26
!qualifier Error
!priority Medium
!difficulty Hard
!subject By-reference types and the recommended level of support for representation clauses
!summary
!question
The recommended level of support for representation items should not preclude maintaining the invariant that all objects of a given by-reference type and all aliased objects of any given type are consistently aligned and have a common representation.
There exist representation items which violate this rule (and which most implementations would therefore reasonably reject) but which are not excluded from the recommended level of support for representation clauses. Was this intended? (No.)
!recommendation
!wording
!discussion
!ACATS test
!appendix

From: Steve Baird
Sent: Tuesday, March 26, 2002  6:39 PM

The recommended level of support for representation items should not
preclude maintaining the invariant that all objects of a given by-reference
type and all aliased objects of any given type are consistently aligned and
have a common representation.

There exist representation items which violate this rule (and which most
implementations would therefore reasonably reject) but which are not excluded
from the recommended level of support for representation clauses.

These include:

1) Alignment clauses for derived tagged types specifying a value which is
   not a multiple of the parent type's alignment (13.1(10) allows this;
   an alignment clause is not a type-related representation item).

   For example:

       type T1 is tagged
           record
               F : Long_Float;
           end record;
       for T1'Alignment use 8; -- ok

       type T2 is new T1 with null record;
       for T2'Alignment use 4; -- bad

       X2 : T2;
       pragma Import (Ada, X2);

       -- Since T1 (X2) may be passed as a parameter to a subprogram,
       -- the subprogram may not assume that its argument is 8-byte
       -- aligned. This is not good.

2) Non-confirming size or alignment clauses for untagged derived
   by-reference types.

   For example:
       type My_Tagged_Type is tagged null record;
       for My_Tagged_Type'Alignment use 4; -- ok

       type Parent is array (1 .. 10) of My_Tagged_Type;
       for Parent'Alignment use 4; -- ok

       type Child is new Parent;
       for Child'Alignment use 8; -- bad

       -- A view conversion may result in a misaligned object of the
       -- more strictly aligned type.

3) Non-confirming size specifications for objects of a by-reference type.

4) Alignment specifications for objects of a by-reference
   type (or which have aliased subcomponents), where the specified
   alignment is not a non-zero multiple of the overridden alignment value.

5) Representation items (e.g. record representation clauses,
   component_size clauses, size clauses, and alignment clauses) which would
   result in misaligned components which are either aliased, contain aliased
   subcomponents, or are of a by-reference type.

   For example:

       type U32 is new Interfaces.Unsigned_32;
       for U32'Size use 32; -- ok
       for U32'Alignment use 4; -- ok

       type R1 is
          record
              F1 : aliased U32;
              F2 : Character;
          end record;
       for R1'Size use 40; -- ok

       type R1_Vec is array (1..10) of R1;
       for R1_Vec'Component_Size use 40; -- bad

   For purposes of this discussion, an object of type T may be "misaligned"
   in either of two ways:
       1) If T'Alignment > 0, then the object is misaligned if its address is
          not an multiple of T'Alignment.
       2) Any object which is not aligned on a storage element boundary
          is considered to be misaligned, regardless of the value of
          T'Alignment (i.e. even if T'Alignment = 0).

   For example:

       type Switch_Setting is (Off, On);
       for Switch_Setting'Alignment use 0; -- ok
       for Switch_Setting'Size use 1; -- ok

       type Setting_Set is array (1..32) of aliased Switch_Setting;
       for Setting_Set'Component_Size use 1; -- bad

6) Representation items which would result in aliased or by_reference
   components having different sizes than they otherwise would have had.

   For example:
       type I16 is new Interfaces.Integer_16;
       for I16'Size use 16; -- ok
       for I16'Alignment use 2; -- ok

       type R2 is
          record
              F : aliased I16;
          end record;

       for R2 use
          record
              F at 0 range 0 .. 31; -- bad
          end record;


Pragma Pack is also problematic. In this example

  type Vec is array (1 .. 32) of aliased Boolean;
  pragma Pack (Vec);

, the Pack pragma should be accepted, but choosing a Component_Size of 8,
rather than 1, for Vec should be consistent with the recommended
level of support for pragma Pack.

These representation items could all be supported (e.g. by representing
access-to-object values and by-reference parameter values as something
other than a simple storage-unit address), but the recommended level
of support for representation items should not require such contortions.

****************************************************************

From: Robert Dewar
Sent: Tuesday, March 26, 2002  9:36 PM

I agree with all Steve's points here, and consider them obvious, in the
sense that no other interpretation makes any sense.

****************************************************************

From: Randy Brukardt
Sent: Friday, April 19, 2002  7:58 PM

I believe each example you provided. But in order to proceed, we'll need to
have references to the particular recommended level of support paragraphs and
some suggestion of how to fix them. I've created an empty AI (AI-291) with just
a question for you to fill in.

Doing this will at least cover part of the ground of the never completed
AI-51/109. I'm sure Bob Duff will be happy that you have volunteered to write
the AI for this albatross^h^h^h^h^h^h^h^h^h issue.

****************************************************************

Questions? Ask the ACAA Technical Agent