Version 1.4 of ais/ai-00291.txt

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

!standard 4.09 (38)          03-09-17 AI95-00291/02
!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
Replace 13.1(24) with
A representation item need not be supported if it could cause an aliased object, a volatile object, or an object of a by-reference type to be allocated at a nonaddressable location or, if the alignment attribute of the subtype of such an object is non-zero, at an address which is not an integral multiple of that alignment.
A representation item need not be supported if it could cause an aliased object or an object whose type is by-reference to have a different size than some other such object of the same definite subtype unless that subtype is discriminated and unconstrained.
A representation item that specifies the default value for an aspect of representation (i.e. the value that would have been chosen in the absence of the representation item) is said to be confirming. A confirming representation item should be supported.
A nonconfirming subtype-specific representation item specifying an aspect of representation of an indefinite subtype need not be supported.
Insert after 13.1(24)
NOTES
The determination of whether a representation item which applies to a type "could cause" an object to have some property should be based solely on the properties of the type itself, not on any available information about how the type is used. In particular, it should be assumed that minimally aligned objects of this type are declared at some point.
Insert after 13.2(6):
If an object of a packed type has a component which is neither aliased nor of a by-reference type, then that component need not be allocated at an addressable location whose address is an integral multiple of the Alignment of the component's subtype.
In 13.2(8), delete
"; the implementation may, but need not, reorder components or cross aligned word boundaries to improve the packing".
Delete 13.3(18)
Replace 13.3(23), sentence 1
"The address of an object that is allocated under control of the implementation is an integral multiple of the Alignment of the object (that is, the Address modulo the Alignment is zero)." with
"<same as before> ... is zero), unless specified otherwise by a representation item."
Insert after 13.3(26)
An implementation need not support Alignments specified for a derived tagged type which are not multiples of the Alignment of the type's parent type. An implementation need not support nonconfirming Alignments specified for a derived untagged by-reference type.
An implementation need not support Alignments specified for objects of a by-reference type or for objects of types containing aliased or volatile subcomponents if the specified Alignment is not a multiple of the Alignment of the object's subtype.
In 13.3(43) replace
"A Size clause should be supported for an object if ..."
with
"A Size clause should be supported for an object (excepting aliased objects, volatile objects, and objects of by-reference types) if ..."
Insert after 13.3(56)
A nonconfirming size clause for the first subtype of a derived untagged by-reference type need not be supported.
In 13.5.1(19), replace
"A storage place should be supported" with "A storage place for an unaliased nonvolatile component should be supported".
Insert after 13.3(72):
An implementation need not support a nonconfirming Component_Size clause if the array type has a by-reference, aliased, or volatile part.
!Discussion
We do not want to require that implementations reject problematic representation items such as
type T is array (1..32) of aliased Boolean; for T'Size use 32;
; we just want to allow implementations to reject such beasts without running afoul of C.2(2).
Note that the term "object" includes the case of a component. Thus, for example, the allowed non-support of a representation clause which could result in a misaligned object would imply permission to reject something like
type Rec1 is record F : aliased Integer; end record; for Rec1'Alignment use Integer'Alignment / 2;
or
type Rec2 is record F : aliased Integer; end record; for Rec2 use record F at Integer'Alignment / 2 range 0 .. Integer'Size - 1; end record;
!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