Contents Index Search Related Documents Previous Next
11.5 Suppressing Checks
1/2
Checking pragmas
give instructions to an implementation on handling language-defined checks.
A
pragma Suppress gives permission
to an implementation to omit certain language-defined checks, while a
pragma Unsuppress revokes the permission
to omit checks..
2
A
language-defined check (or simply, a “check”) is one
of the situations defined by this International Standard that requires
a check to be made at run time to determine whether some condition is
true.
A check
fails when the condition being
checked is false, causing an exception to be raised.
Syntax
3/2
The forms of
checking pragmas are as follows:
4/2
pragma Suppress(
identifier);
4.1/2
pragma Unsuppress(
identifier);
5/2
A
checking pragma is allowed only immediately within a
declarative_part,
immediately within a
package_specification,
or as a configuration pragma.
Legality Rules
6/2
The identifier
shall be the name of a check.
7/2
This paragraph was deleted.
Static Semantics
7.1/2
A checking pragma applies to the named check
in a specific region, and applies to all entities in that region. A checking
pragma given in a declarative_part
or immediately within a package_specification
applies from the place of the pragma
to the end of the innermost enclosing declarative region. The region
for a checking pragma given as a configuration pragma is the declarative
region for the entire compilation unit (or units) to which it applies.
7.2/2
If a checking pragma applies to a generic
instantiation, then the checking pragma also applies to the instance.
If a checking pragma applies to a call to a subprogram that has a pragma
Inline applied to it, then the checking pragma also applies to the inlined
subprogram body.
8/2
A
pragma
Suppress gives permission to an implementation to omit the named check
(or every check in the case of All_Checks) for any entities to which
it applies.
If permission has been given to suppress
a given check, the check is said to be
suppressed.
8.1/2
A pragma
Unsuppress revokes the permission to omit the named check (or every check
in the case of All_Checks) given by any pragma
Suppress that applies at the point of the pragma
Unsuppress. The permission is revoked for the region to which the pragma
Unsuppress applies. If there is no such permission at the point of a
pragma Unsuppress, then the pragma
has no effect. A later pragma Suppress
can renew the permission.
9
The following are
the language-defined checks:
10
- The following
checks correspond to situations in which the exception Constraint_Error
is raised upon failure.
11/2
- Access_Check
-
When evaluating a dereference (explicit or implicit), check that the
value of the name is not null.
When converting to a subtype that excludes null, check that the converted
value is not null.
12
- Discriminant_Check
-
Check that the discriminants of a composite value have the values imposed
by a discriminant constraint. Also, when accessing a record component,
check that it exists for the current discriminant values.
13/2
- Division_Check
-
Check that the second operand is not zero for the operations /, rem
and mod.
14
- Index_Check
-
Check that the bounds of an array value are equal to the corresponding
bounds of an index constraint. Also, when accessing a component of an
array object, check for each dimension that the given index value belongs
to the range defined by the bounds of the array object. Also, when accessing
a slice of an array object, check that the given discrete range is compatible
with the range defined by the bounds of the array object.
15
- Length_Check
-
Check that two arrays have matching components, in the case of array
subtype conversions, and logical operators for arrays of boolean components.
16
- Overflow_Check
-
Check that a scalar value is within the base range of its type, in cases
where the implementation chooses to raise an exception instead of returning
the correct mathematical result.
17
- Range_Check
-
Check that a scalar value satisfies a range constraint. Also, for the
elaboration of a subtype_indication,
check that the constraint (if present)
is compatible with the subtype denoted by the subtype_mark.
Also, for an aggregate, check that
an index or discriminant value belongs to the corresponding subtype.
Also, check that when the result of an operation yields an array, the
value of each component belongs to the component subtype.
18
- Tag_Check
-
Check that operand tags in a dispatching call are all equal. Check for
the correct tag on tagged type conversions, for an assignment_statement,
and when returning a tagged limited object from a function.
19
- The following
checks correspond to situations in which the exception Program_Error
is raised upon failure.
19.1/2
- Accessibility_Check
-
Check the accessibility level of an entity or view.
19.2/2
- Allocation_Check
-
For an allocator, check that the
master of any tasks created by the allocator
is not yet completed or some dependents have not yet terminated, and
that the finalization of the collection has not started.
20
- Elaboration_Check
-
When a subprogram or protected entry is called, a task activation is
accomplished, or a generic instantiation is elaborated, check that the
body of the corresponding unit has already been elaborated.
21/2
- This paragraph was
deleted.
22
- The
following check corresponds to situations in which the exception Storage_Error
is raised upon failure.
23
- Storage_Check
-
Check that evaluation of an allocator
does not require more space than is available for a storage pool. Check
that the space available for a task or subprogram has not been exceeded.
24
- The
following check corresponds to all situations in which any predefined
exception is raised.
25
- All_Checks
-
Represents the union of all checks; suppressing All_Checks suppresses
all checks.
Erroneous Execution
26
If a given check has been
suppressed, and the corresponding error situation occurs, the execution
of the program is erroneous.
Implementation Permissions
27/2
An implementation is allowed to place restrictions
on checking pragmas, subject only to the requirement that
pragma
Unsuppress shall allow any check names supported by
pragma
Suppress. An implementation is allowed to add additional check names,
with implementation-defined semantics.
When Overflow_Check
has been suppressed, an implementation may also suppress an unspecified
subset of the Range_Checks.
27.1/2
An implementation may support an additional
parameter on
pragma Unsuppress similar
to the one allowed for
pragma Suppress
(see
J.10). The meaning of such a parameter
is implementation-defined.
Implementation Advice
28
The implementation should minimize the code executed
for checks that have been suppressed.
29
3 There
is no guarantee that a suppressed check is actually removed; hence a
pragma Suppress should be used only
for efficiency reasons.
29.1/2
4 It is possible to give
both a pragma Suppress and Unsuppress
for the same check immediately within the same declarative_part.
In that case, the last pragma given
determines whether or not the check is suppressed. Similarly, it is possible
to resuppress a check which has been unsuppressed by giving a pragma
Suppress in an inner declarative region.
Examples
30/2
Examples of
suppressing and unsuppressing checks:
31/2
pragma Suppress(Index_Check);
pragma Unsuppress(Overflow_Check);
Contents Index Search Related Documents Previous Next Legal