13.5.1 Record Representation Clauses

{AI95-00114-01} It should be feasible for an implementation to use negative offsets in the representation of composite types. However, no implementation should be forced to support negative offsets. Therefore, in the interest of uniformity, negative offsets should be disallowed in record_representation_clauses.

Reason: First_bit and last_bit need to be simple_expression instead of expression for the same reason as in range (see 3.5, “Scalar Types”). 

Ramification: These need not have the same integer type. 

Ramification: As for all type-related representation items, the local_name is required to denote a first subtype. 

Ramification: A component_clause such as “X at 4 range 0..–1;” is allowed if X can fit in zero bits. 

Reason: It might seem strange to make the record_representation_clause part of the declarative region, and then disallow mentions of the components within almost all of the record_representation_clause. The alternative would be to treat the component_local_name like a formal parameter name in a subprogram call (in terms of visibility). However, this rule would imply slightly different semantics, because (given the actual rule) the components can hide other declarations. This was the rule in Ada 83, and we see no reason to change it. The following, for example, was and is illegal: 

The component X hides the named number X throughout the record_representation_clause.

This paragraph was deleted.Ramification: {AI95-00133-01} For example, if Storage_Unit is 8, then “C at 0 range 24..31;” defines C'Position = 3, C'First_Bit = 0, and C'Last_Bit = 7. This is true of machines with either bit ordering.

A component_clause also determines the value of the Size attribute of the component, since this attribute is related to First_Bit and Last_Bit. 

Implementation defined: Implementation-defined components.

Ramification: Of course, since the semantics of implementation-defined attributes is implementation defined, the implementation need not support these names in all situations. They might be purely for the purpose of component_clauses, for example. The visibility rules for such names are up to the implementation.

We do not allow such component names to be normal identifiers — that would constitute blanket permission to do all kinds of evil things. 

Discussion: Such implementation-defined components are known in the vernacular as “dope.” Their main purpose is for storing offsets of components that depend on discriminants. 

Reason: This is clearly necessary, since the whole record may need to be laid out differently. 

Reason: The above recommendations are sufficient to define interfaces to most interesting hardware. This causes less implementation burden than the definition in ACID, which requires arbitrary bit alignments of arbitrarily large components. Since the ACID definition is neither enforced by the ACVC, nor supported by all implementations, it seems OK for us to weaken it. 

Ramification: Similar permission for other dope is not granted. 

Reason: These restrictions are probably necessary if block equality operations are to be feasible for class-wide types. For block comparison to work, the implementation typically has to fill in any gaps with zero (or one) bits. If a “gap” in the parent type is filled in with a component in a type extension, then this won't work when a class-wide object is passed by reference, as is required. 

Ramification: The visibility rules prevent the name of a component of the type from appearing in a record_representation_clause at any place except for the component_local_name of a component_clause. However, since the record_representation_clause is part of the declarative region of the type declaration, the component names hide outer homographs throughout.

{8652/0009} {AI95-00137-01} A record_representation_clause cannot be given for a protected type, even though protected types, like record types, have components. The primary reason for this rule is that there is likely to be too much dope in a protected type — entry queues, bit maps for barrier values, etc. In order to control the representation of the user-defined components, simply declare a record type, give it a record_representation_clause representation_clause, and give the protected type one component whose type is the record type. Alternatively, if the protected object is protecting something like a device register, it makes more sense to keep the thing being protected outside the protected object (possibly with a pointer to it in the protected object), in order to keep implementation-defined components out of the way. 

The alignment_clause has been renamed to mod_clause and moved to Annex J, “Obsolescent Features”.

We have clarified that implementation-defined component names have to be in the form of an attribute_reference of a component or of the first subtype itself; surely Ada 83 did not intend to allow arbitrary identifiers.

The RM83-13.4(7) wording incorrectly allows components in non-variant records to overlap. We have corrected that oversight. 

{AI95-00133-01} Amendment Correction: The meaning of a record_representation_clause for the nondefault bit order is now clearly defined. Thus, such clauses can be portably written. In order to do that though, the equivalence of bit 1 in word 1 to bit 9 in word 0 (for a machine with Storage_Unit = 8) had to be dropped for the nondefault bit order. Any record_representation_clauses which depends on that equivalence will break (although such code would imply a non-contiguous representation for a component, and it seems unlikely that compilers were supporting that anyway). 

{AI95-00436-01} Amendment Correction: The undocumented (and likely unintentional) incompatibility with Ada 83 caused by not allowing record_representation_clauses on limited record types is removed.