13.9.2 The Valid Attribute
The Valid attribute can be used to check the validity
of data produced by unchecked conversion, input, interface to foreign
languages, and the like.
For a prefix
X that denotes a scalar object [(after any implicit dereference)], the
following attribute is defined:
Yields True if and only if the object denoted by X is normal, has a valid
representation, and then, if the preceding conditions
hold, the value of X also satisfies the predicates the
of the nominal subtype of X evaluates to True
. The value of this attribute is of the predefined
Ramification: Having checked that X'Valid
is True, it is safe to read the value of X without fear of erroneous
execution caused by abnormality, or a bounded error caused by an invalid
representation. Such a read will produce a value in the subtype of X.
data can be created in the following cases (not counting erroneous or
an uninitialized scalar object,
the result of an unchecked conversion,
interface to another language (including
aborting an assignment,
disrupting an assignment due to the
failure of a language-defined check (see 11.6
use of an object whose Address has
Determining whether X is normal and has a valid
representation as part of the evaluation of
X'Valid is not considered
to include an evaluation be
of X; hence, it is not an error to check the validity of
an object that is invalid or abnormal. Determining
whether X satisfies the predicates of its nominal subtype may include
an evaluation of X, but only after it has been determined that X has
a valid representation invalid data
If X is volatile, the evaluation of X'Valid is
considered a read of X.
Reason: Since an
implementation is not allowed to add, remove, or reorder accesses to
volatile objects, we have to define X'Valid as a read so that it is implementable
for most subtypes as the value of the object is required.
The Valid attribute may be used to check the result of calling an instance
of Unchecked_Conversion (or any other operation that can return invalid
values). However, an exception handler should also be provided because
implementations are permitted to raise Constraint_Error or Program_Error
if they detect the use of an invalid representation (see 13.9.1
Ramification: If X is of an enumeration
type with a representation clause, then X'Valid checks that the value
of X when viewed as an integer is one of the specified internal codes.
Reason: Valid is defined only for scalar
objects because the implementation and description burden would be too
high for other types. For example, given a typical run-time model, it
is impossible to check the validity of an access value. The same applies
to composite types implemented with internal pointers. One can check
the validity of a composite object by checking the validity of each of
its scalar subcomponents. The user should ensure that any composite types
that need to be checked for validity are represented in a way that does
not involve implementation-defined components, or gaps between components.
Furthermore, such types should not contain access subcomponents.
Extensions to Ada 83
X'Valid is new in Ada 95.
Wording Changes from Ada 95
Added a note explaining that handlers for Constraint_Error and Program_Error
are needed in the general case of testing for validity. (An implementation
could document cases where these are not necessary, but there is no language
Wording Changes from Ada 2005
The validity check now also includes a check of the predicate aspects
), if any, of the subtype of the
Wording Changes from Ada 2012
Corrigendum: Updated wording of the attributes
X'Valid to use the new term "satisfies the predicates" (see
3.2.4). Also updated the notes to make sense
when evaluating predicates and testing validity of volatile objects.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe