Required enumeration representation clause support AI-00564/03 1
93-06-24 BI WA
| !standard 13.03 (00) 93-06-24 AI-00564/03
!class binding interpretation 88-04-26
| !status approved by WG9 93-06-18
!status ARG-approved 93-01-19 (reviewed)
!status ARG-approved 88-11-01 (9-0-2) (pending editorial review)
!status work-item 88-04-26
!references AI-00138, AI-00561, 83-00916
!topic Required enumeration representation clause support
!SUMMARY 92-02-05
Negative and positive integer values must be allowed as the integer codes in
an enumeration representation clause. At least all values in the range
SYSTEM.MIN_INT .. SYSTEM.MAX_INT must be accepted. An implementation may
optionally allow the use of positive integer values outside this range.
An implementation need not support an enumeration representation clause for a
boolean type.
!QUESTION 92-02-05
13.3(4) specifies that the component type of the aggregate used in an
enumeration representation clause be universal_integer. Clearly, an
implementation will have to impose restrictions on the range of allowed
values of these components. Is such a restriction entirely up to the
implementor, or are there some minimal requirements imposed by the Standard.
In particular, can this range be restricted to natural numbers, i.e.,
unsigned representations? If not, must an implementation accept any integer
value in the range SYSTEM.MIN_INT .. SYSTEM.MAX_INT?
!RECOMMENDATION 92-02-05
Negative and positive integer values must be allowed as the integer codes in
an enumeration representation clause. At least all values in the range
SYSTEM.MIN_INT .. SYSTEM.MAX_INT must be accepted. An implementation may
optionally allow the use of positive integer values outside this range.
An implementation need not support an enumeration representation clause for a
boolean type.
!DISCUSSION 92-02-05
13.3(1, 3, 4) say:
An enumeration representation clause specifies the internal codes for
the literals of the enumeration type that is named in the clause.
The aggregate used to specify this mapping is written as a
one-dimensional aggregate, for which the index subtype is the
enumeration type and the component type is universal_integer.
Required enumeration representation clause support AI-00564/03 2
93-06-24 BI WA
... The integer codes specified for the enumeration type must satisfy
the predefined ordering relation of the type.
The use of an enumeration representation clause affects the implementation of
indexing, case selection, iteration, and the attributes 'SIZE, 'POS, 'VAL,
'SUCC, 'PRED, 'IMAGE, and 'VALUE. In general, to support these operations,
an implementation will need to maintain two mapping tables. One table is
simply the aggregate given in the enumeration representation clause; this
table provides the mapping from logical values to integer codes. The other
table specifies the mapping from user-defined integer codes to
language-defined (contiguous) logical values. When there are few enumeration
values and large gaps between integer codes, an implementation could run out
of storage if it used a direct indexing approach for mapping from integer
codes to logical values. Since a linear search approach would not exhaust
storage, and since enumeration representation clauses must be supported in
general, it would be unacceptable for an implementation to, in effect, fail
to support an enumeration representation clause because the implementation
used an inappropriate approach for organizing and accessing the
codes-to-values table.
Since boolean types are generally treated specially by an implementation, it
is not required that enumeration representation clauses be supported for
derived boolean types.
If the maximum size for an integer type is, say, 16 bits, an implementation
is allowed (but not required) to support integer codes up to 2**16 - 1, even
though such values could not normally be stored as values of an integer type
because they exceed SYSTEM.MAX_INT (which is 2**15-1) (see AI-00402).
However, support for such unsigned integer values is potentially complex.
For example, the relational and successor/predecessor operations must be
implemented to produce correct results for unsigned 16-bit integer codes
since the normal predefined operations will not work correctly for an
unsigned representation. In effect, the use of this form of representation
requires modifying essentially all the predefined operations for enumeration
types. Since this form of representation is not necessarily useful, this
support is not required of all implementations. Of course, even if this
capability is not supported, negative integer values can be used to specify
equivalent bit patterns. However, since the ordering of the integer codes
and the ordering of the enumeration values must be the same, enumeration
literals having negative integer codes must occur before literals having a
positive integer code.
For example, consider an enumeration type with two values, A and B. Suppose A
is to have the representation 16#8000#, and 16 bits is the maximum signed
integer representation supported by the implementation. Suppose B is to have
the representation 16#00FF#. Since the specified integer codes must satisfy
the predefined ordering relation of the type, the representation for A must
be numerically less than the representation for B. Hence, we must write:
type ENUM is (A, B);
for ENUM use (-2**16, 16#00FF#); -- must be supported
Required enumeration representation clause support AI-00564/03 3
93-06-24 BI WA
(This representation clause assumes twos-complement representation for
negative numbers.)
If an unsigned 16-bit representation is supported we could write the desired
bit patterns directly, after being careful to preserve the required ordering
relationships:
type ENUM2 is (B, A);
for ENUM2 use (16#00FF#, 16#8000#); -- optionally supported
for ENUM2'SIZE use 16;