13.2 Packed Types

danger

This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue

1/3

[The Pack aspect having the value True specifies that storage minimization should be the main criterion when selecting the representation of a composite type.]

Paragraphs 2 through 4 were moved to Annex J, “Obsolescent Features”.

Language Design Principles

1.a/4

note

If the default representation already uses minimal storage for a particular type, aspect Pack might not cause any representation change. It follows that aspect Pack should always be allowed, even when it has no effect on representation.

1.b/4

note

As a consequence, the chosen representation for a packed type may change during program maintenance even if the type is unchanged (in particular, if other representation aspects change on a part of the type). This is different than the behavior of most other representation aspects, whose properties remain guaranteed no matter what changes are made to other aspects.

1.c/4

note

Therefore, aspect Pack should not be used to achieve a representation required by external criteria. For instance, setting Component_Size to 1 should be preferred over using aspect Pack to ensure an array of bits. If future maintenance would make the array components aliased, independent, or atomic, the program would become illegal if Component_Size is used (immediately identifying a problem) while the aspect Pack version would simply change representations (probably causing a hard-to-find bug).

Static Semantics

5/3

For a full type declaration of a composite type, the following language-defined representation aspect may be specified:

5.1/3

Pack

The type of aspect Pack is Boolean. When aspect Pack is True for a type, the type (or the extension part) is said to be packed. For a type extension, the parent part is packed as for the parent type, and specifying Pack causes packing only of the extension part.

5.a/3

note

Aspect Description for Pack: Minimize storage when laying out records and arrays.

5.2/3

If directly specified, the aspect_definition shall be a static expression. If not specified (including by inheritance), the aspect is False.

5.b/3

ramification

The only high level semantic effect of specifying the Pack aspect is potential loss of independent addressability (see 9.10, “Shared Variables”).]

Implementation Advice

6

If a type is packed, then the implementation should try to minimize storage allocated to objects of the type, possibly at the expense of speed of accessing components, subject to reasonable complexity in addressing calculations.

6.a.1/2

implementation advice

Storage allocated to objects of a packed type should be minimized.

6.a/3

ramification

Specifying the Pack aspect is for gaining space efficiency, possibly at the expense of time. If more explicit control over representation is desired, then a record_representation_clause, a Component_Size clause, or a Size clause should be used instead of, or in addition to, the Pack aspect.

6.1/4

This paragraph was deleted.

7/3

The recommended level of support for the Pack aspect is:

7.1/4

• Any component of a packed type that is of a by-reference type, that is specified as independently addressable, or that contains an aliased part, shall be aligned according to the alignment of its subtype.
  

7.a/4

ramification

This also applies to atomic components. "Atomic" implies "specified as independently addressable", so we don't need to mention atomic here.

7.b/4

note

Other components do not have to respect the alignment of the subtype when packed; in many cases, the Recommended Level of Support will require the alignment to be ignored.

8/5

• For a packed record type, the components should be packed as tightly as possible subject to the above alignment requirements, the Sizes of the component subtypes, and any record_representation_clause that applies to the type; the implementation is allowed to reorder components or cross aligned word boundaries to improve the packing. A component whose Size is greater than the word size may be allocated an integral number of words.
  

8.a

ramification

The implementation can always allocate an integral number of words for a component that will not fit in a word. The rule also allows small component sizes to be rounded up if such rounding does not waste space. For example, if Storage_Unit = 8, then a component of size 8 is probably more efficient than a component of size 7 plus a 1-bit gap (assuming the gap is needed anyway).

9/4

• For a packed array type, if the Size of the component subtype is less than or equal to the word size, Component_Size should be less than or equal to the Size of the component subtype, rounded up to the nearest factor of the word size, unless this would violate the above alignment requirements.
  

9.a/4

note

This paragraph was deleted.

9.b/3

implementation advice

The recommended level of support for the Pack aspect should be followed.

Wording Changes from Ada 95

9.c/3

note

Added clarification that the Pack aspect can ignore alignment requirements on types that don't have by-reference or aliased parts. This was always intended, but there was no wording to that effect.

Extensions to Ada 2005

9.d/3

note

Aspect Pack is new; pragma Pack is now obsolescent.

Wording Changes from Ada 2005

9.e/3

correction

Fixed so that the presence or absence of a confirming Component_Size representation clause does not change the meaning of the Pack aspect.

Wording Changes from Ada 2012

9.f/4

note

Corrigendum: Fixed so that the Recommended Level of Support does not require packing of components for which such packing would violate other representation items or aspects. This is not incompatible, as either such Pack aspects were treated as illegal or the Recommended Level of Support was ignored as impractical, neither of which would change the behavior of any working programs. (Other behavior cannot be justifed from the Reference Manual.)