Version 1.5 of ais/ai-00291.txt
!standard 4.09 (38) 03-09-17 AI95-00291/02
!class binding interpretation 02-03-26
!status work item 03-09-17
!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