Contents Index Search Previous Next
11.5 Suppressing Checks
1
A pragma
Suppress gives permission to an implementation to omit certain language-defined
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
The form of
a pragma Suppress is as follows:
4
pragma Suppress(
identifier
[, [On =>]
name]);
5
A
pragma Suppress is allowed only
immediately within a
declarative_part,
immediately within a
package_specification,
or as a configuration pragma.
Legality Rules
6
The identifier
shall be the name of a check. The name
(if present) shall statically denote some entity.
7
For a pragma
Suppress that is immediately within a package_specification
and includes a name, the name
shall denote an entity (or several overloaded subprograms) declared immediately
within the package_specification.
Static Semantics
8
A
pragma
Suppress gives permission to an implementation to omit the named check
from the place of the
pragma to
the end of the innermost enclosing declarative region, or, if the
pragma
is given in a
package_specification
and includes a
name, to the end
of the scope of the named entity. If the
pragma
includes a
name, the permission
applies only to checks performed on the named entity, or, for a subtype,
on objects and values of its type. Otherwise, the permission applies
to all entities.
If permission has been given to
suppress a given check, the check is said to be
suppressed.
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/1
- Access_Check
-
When evaluating a dereference (explicit or implicit), check that the
value of the name is not null.
When passing an actual parameter to a formal access parameter, check
that the value of the actual parameter is not null. When evaluating
a discriminant_association for an
access discriminant, check that the value of the discriminant 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
- 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.
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
- Accessibility_Check
-
Check the accessibility level of an entity or view.
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
An implementation is allowed to place restrictions
on Suppress
pragmas. 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.
Implementation Advice
28
The implementation should minimize the code executed
for checks that have been suppressed.
29
2 There
is no guarantee that a suppressed check is actually removed; hence a
pragma Suppress should be used only
for efficiency reasons.
Examples
30
Examples of
suppressing checks:
31
pragma Suppress(Range_Check);
pragma Suppress(Index_Check, On => Table);
Contents Index Search Previous Next Legal