13.1 Operational and Representation Aspects

{8652/0009} {AI95-00137-01} {AI05-0295-1} Representation aspects are intended to refer to properties that need to be known before the compiler can generate code to create or access an entity. For instance, the size of an object needs to be known before the object can be created. Conversely, operational aspects are those that only need to be known before they can be used. For instance, how an object is read from a stream only needs to be known when a stream read is executed. Thus, representation aspects have stricter rules as to when they can be specified.

{AI95-00291-02} {AI05-0295-1} Confirming the value of an aspect should never change the semantics of the aspect. Thus Size = 8 (for example) means the same thing whether it was specified with a representation item or whether the compiler chose this value by default. 

Glossary entry: An aspect is a specifiable property of an entity. An aspect may be specified by an aspect_specification on the declaration of the entity. Some aspects may be queried via attributes.

Reason: {8652/0009} {AI95-00137-01} This is a Name Resolution Rule, because we don't want an operational or representation item for X to be ambiguous just because there's another X declared in an outer declarative region. It doesn't make much difference, since most operational or representation items are for types or subtypes, and type and subtype names can't be overloaded. 

Ramification: {8652/0009} {AI95-00137-01} The visibility rules imply that the declaration has to occur before the operational or representation item.

{8652/0009} {AI95-00137-01} For objects, this implies that operational or representation items can be applied only to stand-alone objects. 

Ramification: The “statically denote” part implies that it is impossible to specify the representation of an object that is not a stand-alone object, except in the case of a representation item like pragma Atomic that is allowed inside a component_list (in which case the representation item specifies the representation of components of all objects of the type). It also prevents the problem of renamings of things like “P.all” (where P is an access-to-subprogram value) or “E(I)” (where E is an entry family).

The part about where the denoted entity has to have been declared appears twice — once as a Name Resolution Rule, and once as a Legality Rule. Suppose P renames Q, and we have a representation item in a declarative_part whose local_name is P. The fact that the representation item has to appear in the same declarative_part as P is a Name Resolution Rule, whereas the fact that the representation item has to appear in the same declarative_part as Q is a Legality Rule. This is subtle, but it seems like the least confusing set of rules. 

Discussion: A separate Legality Rule applies for component_clauses. See 13.5.1, “Record Representation Clauses”. 

To be honest: {AI95-00291-02} Discontiguous representations are allowed, but the ones we're interested in here are generally contiguous sequences of bits. For a discontiguous representation, the size doesn't necessarily describe the “footprint” of the object in memory (that is, the amount of space taken in the address space for the object).

Discussion: {AI95-00291-02} In the case of composite objects, we want the implementation to have the flexibility to either do operations component-by-component, or with a block operation covering all of the bits. We carefully avoid giving a preference in the wording. There is no requirement for the choice to be documented, either, as the implementation can make that choice based on many factors, and could make a different choice for different operations on the same object.

{AI95-00291-02} In the case of a properly aligned, contiguous object whose size is a multiple of the storage unit size, no other bits should be read or updated as part of operating on the object. We don't say this normatively because it would be difficult to normatively define “properly aligned” or “contiguous”. 

Ramification: Two objects with the same value do not necessarily have the same representation. For example, an implementation might represent False as zero and True as any odd value. Similarly, two objects (of the same type) with the same sequence of bits do not necessarily have the same value. For example, an implementation might use a biased representation in some cases but not others: 

The implementation might use a biased-by-1 representation for the array elements, but not for X. X and Y(3) have the same value, but different representation: the representation of X is a sequence of (say) 32 bits: 0...011, whereas the representation of Y(3) is a sequence of 8 bits: 00000010 (assuming a two's complement representation).

Such tricks are not required, but are allowed.

Discussion: The value of any padding bits is not specified by the language, though for a numeric type, it will be much harder to properly implement the predefined operations if the padding bits are not either all zero, or a sign extension. 

Ramification: {AI05-0229-1} For example, suppose S'Size = 2, and an object X is of subtype S. If the machine code typically uses a 32-bit load instruction to load the value of X, then X'Size should be 32, even though 30 bits of the value are just zeros or sign-extension bits. On the other hand, if the machine code typically masks out those 30 bits, then X'Size should be 2. Usually, such masking only happens for components of a composite type for which Pack, Component_Size, or record layout is specified.

Note, however, that the formal parameter of an instance of Unchecked_Conversion is a special case. Its Size is required to be the same as that of its subtype.

Note that we don't generally talk about the representation of a value. A value is considered to be an amorphous blob without any particular representation. An object is considered to be more concrete. 

To be honest: Type-related and subtype-specific are defined likewise for the corresponding aspects of representation. 

To be honest: Some representation items directly specify more than one aspect. 

Discussion: {AI05-0229-1} For example, a pragma Export (see J.15.5) specifies the convention of an entity, and also specifies that it is exported. Such items are obsolescent; directly specifying the associated aspects is preferred.

Ramification: Each specifiable attribute constitutes a separate aspect. An enumeration_representation_clause specifies the coding aspect. A record_representation_clause (without the mod_clause) specifies the record layout aspect. Each representation pragma specifies a separate aspect. 

Reason: We don't need to say that an at_clause or a mod_clause specify separate aspects, because these are equivalent to attribute_definition_clauses. See J.7, “At Clauses”, and J.8, “Mod Clauses”.

{AI05-0112-1} We give a default naming for representation aspects of representation pragmas so we don't have to do that for every pragma. Operational and representation attributes are given a default naming in 13.3. We don't want any anonymous aspects; that would make other rules more difficult to write and understand. 

Ramification: The following representation items are type-related: 

The following representation items are subtype-specific: 

The following representation items do not apply to subtypes, so they are neither type-related nor subtype-specific: 

{AI05-0229-1} While an aspect_specification is not a representation item, a similar categorization applies to the aspect that corresponds to each of these representation items (along with aspects that do not have associated representation items). 

Ramification: {8652/0009} {AI95-00137-01} The following operational items are type-related: 

Ramification: {8652/0009} {AI95-00137-01} The fact that a representation item (or operational item, see next paragraph) that directly specifies an aspect of an entity is required to appear before the entity is frozen prevents changing the representation of an entity after using the entity in ways that require the representation to be known. 

This paragraph was deleted.{AI05-0183-1} {AI12-0116-1}

Ramification: Unlike representation items, operational items can be specified on partial views. Since they don't affect the representation, the full declaration need not be known to determine their legality. 

Ramification: {AI12-0116-1} This rule applies to all aspects, not just those that are operational aspects or representation aspects. For instance, it applies to subtype predicates and type invariants. 

To be honest: {AI12-0116-1} This rule is also intended to cover other ways to specify representation aspects, such as obsolescent pragma Priority. Priority is not a representation pragma, and as such is neither a representation item nor an aspect_specification. Regardless, giving both a pragma Priority and an aspect_specification for Priority is illegal. We didn't want to complicate the wording solely to support obsolescent features. 

Reason: Specifying an aspect on a generic formal parameter implies an added contract for a generic unit. That contract needs to be defined via generic parameter matching rules, and, as aspects vary widely, that has to be done for each such aspect. Since most aspects do not need this complexity (including all language-defined aspects as of this writing), we avoid the complexity by saying that such contract-forming aspect specifications are banned unless the rules defining them explicitly exist. Note that the method of specification does not matter: aspect_specifications, representation items, and operational items are all covered by this (and similar) rules. 

Ramification: {8652/0009} {AI95-00137-01} {AI05-0295-1} On the other hand, subtype-specific representation aspects may be specified for the first subtype of such a type, as can operational aspects. 

Reason: {AI05-0229-1} {AI05-0295-1} {AI12-0109-1} The reason for forbidding specification of type-related representation aspects on untagged by-reference types is because a change of representation is impossible when passing by reference (to an inherited subprogram). (A by-reference object cannot be copied to change its representation.) The reason for forbidding specification of type-related representation aspects on untagged types with user-defined primitive subprograms was to prevent implicit change of representation for type-related aspects of representation upon calling inherited subprograms, because such changes of representation are likely to be expensive at run time. Changes of subtype-specific representation attributes, however, are likely to be cheap. This rule is not needed for tagged types, because other rules prevent a type-related representation aspect from changing the representation of the parent part; we want to allow specifying a type-related representation aspect on a type extension to specify aspects of the extension part. For example, specifying aspect Pack will cause packing of the extension part, but not of the parent part. 

Discussion: {AI12-0109-1} “By-reference type” usually cannot be used in Legality Rules, as it is privacy breaking. Our use here is privacy breaking, but we're stuck with it for compatibility reasons. Since representation aspects cannot be specified on partial views, privacy violations only can happen when a type includes a component of a private type. In that case, whether these rules are triggered depends on the full type of the private type — which is clearly privacy breaking. 

Ramification: {8652/0009} {AI95-00137-01} {AI05-0295-1} Specifying representation aspects is allowed for types whose subcomponent types or index subtypes are generic formal types. Specifying operational aspects and subtype-related representation aspects is allowed on descendants of generic formal types. 

Reason: {AI05-0295-1} Since it is not known whether a formal type has user-defined primitive subprograms, specifying type-related representation aspects for them is not allowed, unless they are tagged (in which case only the extension part is affected in any case). 

Ramification: {AI95-00326-01} All views of a type, including the incomplete and partial views, have the same operational and representation aspects. That's important so that the properties don't change when changing views. While most aspects are not available for an incomplete view, we don't want to leave any holes by not saying that they are the same.

{AI05-0083-1} However, this does not apply to objects. Different views of an object can have different representation aspects. For instance, an actual object passed by reference and the associated formal parameter may have different values for Alignment even though the formal parameter is merely a view of the actual object. This is necessary to maintain the language design principle that Alignments are always known at compile time. 

Implementation defined: The cases that cause conflicts between the representation of the ancestors of a type_declaration.

Reason: {AI05-0295-1} This rule is needed because it may be the case that only the combination of types in a type declaration causes a conflict. Thus it is not possible, in general, to reject the original representation item or aspect_specification. For instance: 

Assume the implementation uses a single tag with a default offset of zero, and that it allows the use of nondefault locations for the tag (and thus accepts representation items like the one above). The representation item will force a nondefault location for the tag (by putting a component other than the tag into the default location). Clearly, this package will be accepted by the implementation. However, other declarations could cause trouble. For instance, the implementation could reject: 

{AI05-0295-1} because the declarations of T and Ifc have a conflict in their representation items. This is clearly necessary (it's hard to imagine how Ifc'Class could work with the tag at a location other than the one it is expecting without introducing distributed overhead).

{AI05-0295-1} Conflicts will usually involve implementation-defined attributes (for specifying the location of the tag, for instance), although the example above shows that doesn't have to be the case. For this reason, we didn't try to specify exactly what causes a conflict; it will depend on the implementation's implementation model and what representation aspects it allows to be changed. 

Implementation Note: {AI05-0295-1} An implementation can only use this rule to reject type_declarations where one of its ancestors had a nonconfirming representation value specified. An implementation must ensure that the default representations of ancestors cannot conflict. 

Reason: {AI05-0295-1} This is necessary because we allow (for example) conversion between access types whose designated subtypes statically match. Note that most aspects (including the subtype-specific aspects Size and Alignment) may not be specified for a nonfirst subtype. The only language-defined exceptions to this rule are the Static_Predicate and Dynamic_Predicate aspects.

Consider, for example: 

Loads and stores through X1 would read and write 16 bits, but X1 points to a 32-bit location. Depending on the endianness of the machine, loads might load the wrong 16 bits. Stores would fail to zero the other half in any case.

Loads and stores through X2 would read and write 32 bits, but X2 points to a 16-bit location. Thus, adjacent memory locations would be trashed.

Hence, the above is illegal. Furthermore, the compiler is forbidden from choosing different Sizes by default, for the same reason.

The same issues apply to Alignment.

To be honest: A record_representation_clause for a record extension does not override the layout of the parent part; if the layout was specified for the parent type, it is inherited by the record extension. 

Ramification: If a representation item for the parent appears after the derived_type_definition, then inheritance does not happen for that representation item.

{AI05-0009-1} {AI05-0295-1} If an inherited aspect is confirmed by an aspect_specification or a later representation item for a derived type, the confirming specification does not override the inherited one. Thus the derived type has both a specified confirming value and an inherited nonconfirming representation value — this means that rules that apply only to nonconfirming representation values still apply to this type.

{AI12-0109-1} If an aspect was specified by an aspect_specification and the parent type has not yet been frozen, then the inherited aspect might not yet have been resolved and evaluated. The implementation will need to have a mechanism to handle such an aspect. 

Ramification: As with representation items, if an operational item for the parent appears after the derived_type_definition, then inheritance does not happen for that operational item. 

Reason: This defines the parameter names and types, and the needed implicit conversions. 

Ramification: This rule implies that queries of the aspect return the specified value. For example, if the user writes “for X'Size use 32;”, then a query of X'Size will return 32. 

Ramification: {8652/0009} {AI95-00137-01} {AI05-0295-1} Note that specifying a representation aspect can affect the semantics of the entity.

The rules forbid things like “for S'Base'Alignment use ...” and “for S'Base use record ...”. 

Discussion: The intent is that implementations will represent the components of a composite value in the same way for all subtypes of a given composite type. Hence, Component_Size and record layout are type-related aspects. 

Ramification: {AI05-0083-1} As noted previously, in the case of an object, the entity mentioned in this text is a specific view of an object. That means that only references to the same view of an object that has a specified value for a representation aspect R necessarily have that value for the aspect R. The value of the aspect R for a different view of that object is unspecified. In particular, this means that the representation values for by-reference parameters is unspecified; they do not have to be the same as those of the underlying object. 

Ramification: {AI05-0299-1} Elaboration of representation pragmas is covered by the general rules for pragmas in 2.8. 

Implementation defined: The interpretation of each representation aspect.

Implementation defined: Any restrictions placed upon the specification of representation aspects.

Ramification: Implementation-defined restrictions may be enforced either at compile time or at run time. There is no requirement that an implementation justify any such restrictions. They can be based on avoiding implementation complexity, or on avoiding excessive inefficiency, for example.

{8652/0009} {AI95-00137-01} There is no such permission for operational aspects. 

To be honest: {AI05-0295-1} A confirming representation aspect value might not be possible for some entities. For instance, consider an unconstrained array. The size of such a type is implementation-defined, and might not actually be a representable value, or might not be static. 

Reason: This is to avoid the following sort of thing: 

In the above, we have to evaluate the initialization expression for X before we know where to put the result. This seems like an unreasonable implementation burden.

The above code should instead be written like this: 

This allows the expression “Y” to be safely evaluated before X is created.

The constant could be a formal parameter of mode in.

An implementation can support other nonstatic expressions if it wants to. Expressions of type Address are hardly ever static, but their value might be known at compile time anyway in many cases. 

Reason: The intent is that access types, type System.Address, and the pointer used for a by-reference parameter should be implementable as a single machine address — bit-field pointers should not be required. (There is no requirement that this implementation be used — we just want to make sure it's feasible.) 

Implementation Note: {AI95-00291-02} We want subprograms to be able to assume the properties of the types of their parameters inside of subprograms. While many objects can be copied to allow this (and thus do not need limitations), aliased or by-reference objects cannot be copied (their memory location is part of their identity). Thus, the above rule does not apply to types that merely allow by-reference parameter passing; for such types, a copy typically needs to be made at the call site when a bit-aligned component is passed as a parameter.

Reason: Since all bits of elementary objects participate in operations, aliased objects must not have a different size than that assumed by users of the access type. 

Reason: Unlike elementary objects, there is no requirement that all bits of a composite object participate in operations. Thus, as long as the object is the same or larger in size than that expected by the access type, all is well. 

Ramification: This rule presumes that the implementation allocates an object of a size specified to be larger than the default size in such a way that access of the default size suffices to correctly read and write the value of the object. 

Reason: {AI05-0295-1} Representation aspects are often not well-defined for such types. 

Ramification: {AI95-00291-02} {AI05-0229-1} A type with the Pack aspect specified will typically not be packed so tightly as to disobey the above rules. A Component_Size clause or record_representation_clause will typically be illegal if it disobeys the above rules. Atomic components have similar restrictions (see C.6, “Shared Variable Control”). 

Implementation Advice: The recommended level of support for all representation items should be followed.

It is now illegal for a representation item to cause a derived by-reference type to have a different record layout from its parent. This is necessary for by-reference parameter passing to be feasible. This only affects programs that specify the representation of types derived from types containing tasks; most by-reference types are new to Ada 95. For example, if A1 is an array of tasks, and A2 is derived from A1, it is illegal to apply a pragma Pack to A2. 

{8652/0009} {AI95-00137-01} Ada 95 allows additional aspect_clauses for objects. 

{8652/0009} {AI95-00137-01} The syntax rule for type_representation_clause is removed; the right-hand side of that rule is moved up to where it was used, in aspect_clause. There are two references to “type representation clause” in RM83, both in Section 13; these have been reworded. Also, the representation_clause has been renamed the aspect_clause to reflect that it can be used to control more than just representation aspects.

{8652/0009} {AI95-00137-01} {AI95-00114-01} We have defined a new term “representation item,” which includes all representation clauses and representation pragmas, as well as component_clauses. This is convenient because the rules are almost identical for all of them. We have also defined the new terms “operational item” and “operational aspects” in order to conveniently handle new types of specifiable entities.

All of the forcing occurrence stuff has been moved into its own subclause (see 13.14), and rewritten to use the term “freezing”.

RM83-13.1(10) requires implementation-defined restrictions on representation items to be enforced at compile time. However, that is impossible in some cases. If the user specifies a junk (nonstatic) address in an address clause, and the implementation chooses to detect the error (for example, using hardware memory management with protected pages), then it's clearly going to be a run-time error. It seems silly to call that “semantics” rather than “a restriction.”

RM83-13.1(10) tries to pretend that representation_clauses don't affect the semantics of the program. One counter-example is the Small clause. Ada 95 has more counter-examples. We have noted the opposite above.

Some of the more stringent requirements are moved to C.2, “Required Representation Support”. 

{AI95-00291-02} Amendment Correction: Confirming representation items are defined, and the recommended level of support is now that they always be supported. 

{8652/0009} {AI95-00137-01} Corrigendum: Added operational items in order to eliminate unnecessary restrictions and permissions on stream attributes. As part of this, representation_clause was renamed to aspect_clause.

{8652/0009} {AI95-00137-01} {AI95-00326-01} Corrigendum: Added wording to say that the partial and full views have the same operational and representation aspects. Ada 2005 extends this to cover all views, including the incomplete view.

{8652/0040} {AI95-00108-01} Corrigendum: Changed operational items to have inheritance specified for each such aspect.

{AI95-00251-01} Added wording to allow the rejection of types with progenitors that have conflicting representation items.

{AI95-00291-02} The description of the representation of an object was clarified (with great difficulty reaching agreement). Added wording to say that representation items on aliased and by-reference objects never need be supported if they would not be implementable without distributed overhead even if other recommended level of support says otherwise. This wording matches the rules with reality.

{AI95-00444-01} {AI05-0005-1} Added wording so that inheritance depends on whether operational items are visible rather than whether they occur before the declaration (we don't want to look into private parts). Also limited operational inheritance to untagged types to avoid anomalies with private extensions (this is not incompatible, no existing operational attribute used this capability). Also added wording to clearly define that subprogram inheritance works like derivation of subprograms. 

{AI05-0106-1} Correction: Specifying a language-defined aspect for a generic formal parameter is no longer allowed. Most aspects could not be specified on these anyway; moreover, this was not allowed in Ada 83, so it is unlikely that compilers are supporting this as a capability (and it is not likely that they have a consistent definition of what it means if it is allowed). Thus, we expect this to occur rarely in existing programs. 

{AI05-0009-1} Correction: Defined that overriding of an representation aspect only happens for a nonconfirming representation item. This prevents a derived type from being considered to have only a confirming representation item when the value would be nonconfirming if given on a type that does not inherit any aspects of representation. This change just eliminates a wording confusion and ought not change any behavior.

{AI05-0112-1} Correction: Defined a default naming for representation aspects that are representation pragmas.

{AI05-0183-1} Added text ensuring that the rules for representational and operational items also apply appropriately to aspect_specifications; generalized operational aspects so that they can be defined for entities other than types. Any extensions are documented elsewhere.

{AI05-0295-1} Rewrote many rules to be in terms of "specifying a representation aspect" rather than use of a "representation item". This better separates how an aspect is specified from what rules apply to the value of the aspect. 

{AI12-0109-1} Corrigendum: Added a rule that makes it illegal to specify a representation value after a type is derived from an untagged by-reference type. This restriction is incompatible, but since the implementation would have had to copy an object that does not allow copying in order to change the representation for any implicit or explicit conversion between the original and the derived type, it is unlikely that any program could exist without running into internal compiler errors or bogus results.

{AI12-0116-1} Corrigendum: Clarified that an aspect (any aspect) can be specified only once for an entity, no matter what means of specifying it are used. We did not document this as an incompatibility as only aspects that are neither operational nor representation could change behavior and there is no known implementation of these new aspects that allows multiple definitions.