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