Go to the first, previous, next, last section, table of contents.

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]);
    1. A pragma Suppress is allowed only immediately within a declarative_part, immediately within a package_specification, or as a configuration pragma.

Legality Rules

  1. The identifier shall be the name of a check. The name (if present) shall statically denote some entity.
  2. 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

  3. 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.
  4. The following are the language-defined checks:
    1. The following checks correspond to situations in which the exception Constraint_Error is raised upon failure.
      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.
      2. 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.
      3. Division_Check 
        Check that the second operand is not zero for the
operations /, rem and mod.
      4. 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.
      5. Length_Check 
        Check that two arrays have matching components,
in the case of array subtype conversions, and
logical operators for arrays of boolean
components.
      6. 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.
      7. 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.
      8. 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.

    1. The following checks correspond to situations in which the exception Program_Error is raised upon failure.
      1. 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.
      2. Accessibility_Check 
        Check the accessibility level of an entity or
view.

    1. The following check corresponds to situations in which the exception Storage_Error is raised upon failure.
      1. 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.

    1. The following check corresponds to all situations in which any predefined exception is raised.
      1. All_Checks 
        Represents the union of all checks; suppressing
All_Checks suppresses all checks.

Erroneous Execution

  1. If a given check has been suppressed, and the corresponding error situation occurs, the execution of the program is erroneous.

    Implementation Permissions

  2. 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

  3. The implementation should minimize the code executed for checks that have been suppressed.

    NOTES

  4. (2) There is no guarantee that a suppressed check is actually removed; hence a pragma Suppress should be used only for efficiency reasons.

    Examples

  5. Examples of suppressing checks: 
  6. pragma Suppress(Range_Check);
pragma Suppress(Index_Check, On => Table);

Go to the first, previous, next, last section, table of contents.