- 22 ·
- An implementation need not support representation items containing nonstatic expressions, except that an implementation should support a representation item for a given entity if each nonstatic expression in the representation item is a name that statically denotes a constant declared before the entity.
- 22.a
- Reason: This is to avoid the following sort of thing:
- 22.b
- X : Integer := F(...);
Y : Address := G(...);
for X'Address use Y;
- 22.c
- 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.
- 22.d
- The above code should instead be written like this:
- 22.e
- Y : constant Address := G(...);
X : Integer := F(...);
for X'Address use Y;
- 22.f
- This allows the expression "Y" to be safely evaluated before X is created.
- 22.g
- The constant could be a formal parameter of mode in.
- 22.h
- 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.
- 23 ·
- An implementation need not support a specification for the Size for a given composite subtype, nor the size or storage place for an object (including a component) of a given composite subtype, unless the constraints on the subtype and its composite subcomponents (if any) are all static constraints.
- 24 ·
- An aliased component, or a component whose type is by-reference, should always be allocated at an addressable location.
- 24.a
- 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 its feasible.)
- 24.b
- Implementation Note: Note that 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.
- 24.c
- Ramification: A pragma Pack will typically not pack so tightly as to disobey the above rule. A Component_Size clause or record_representation_clause will typically by illegal if it disobeys the above rule. Atomic components have similar restrictions (see C.6, "Shared Variable Control").
- Incompatibilities With Ada 83
- 24.d
- 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 9X. 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.
- Extensions to Ada 83
- 24.e
- Ada 9X allows additional representation_clauses for objects.
- Wording Changes From Ada 83
- 24.f
- 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 representation_clause. There are two references to "type representation clause" in RM83, both in Section 13; these have been reworded.
- 24.g
- We have defined a new term "representation item," which includes both representation_clauses and representation pragmas, as well as component_clauses. This is convenient because the rules are almost identical for all three.
- 24.h
- All of the forcing occurrence stuff has been moved into its own subclause (see 13.14), and rewritten to use the term "freezing".
- 24.i
- 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."
- 24.j
- 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 9X has more counter-examples. We have noted the opposite above.
- 24.k
- Some of the more stringent requirements are moved to C.2, "Required Representation Support".