11.7. Suppressing Checks

The presence of a SUPPRESS pragma gives permission to an implementation to omit certain run-time checks. The form of this pragma is as follows:

    pragma SUPPRESS(identifier [, [ON =>] name]);   

The identifier is that of the check that can be omitted. The name (if present) must be either a simple name or an expanded name and it must denote either an object, a type or subtype, a task unit, or a generic unit; alternatively the name can be a subprogram name, in which case it can stand for several visible overloaded subprograms.

A pragma SUPPRESS is only allowed immediately within a declarative part or immediately within a package specification. In the latter case, the only allowed form is with a name that denotes an entity (or several overloaded subprograms) declared immediately within the package specification. The permission to omit the given check extends from the place of the pragma to the end of the declarative region associated with the innermost enclosing block statement or program unit. For a pragma given in a package specification, the permission extends to the end of the scope of the named entity.

If the pragma includes a name, the permission to omit the given check is further restricted: it is given only for operations on the named object or on all objects of the base type of a named type or subtype; for calls of a named subprogram; for activations of tasks of the named task type; or for instantiations of the given generic unit.

The following checks correspond to situations in which the exception CONSTRAINT_ERROR may be raised; for these checks, the name (if present) must denote either an object or a type.

• ACCESS_CHECK When accessing a selected component, an indexed component, a slice, or an attribute, of an object designated by an access value, check that the access value is not null.

• DISCRIMINANT_CHECK Check that a discriminant of a composite value has the value imposed by a discriminant constraint. Also, when accessing a record component, check that it exists for the current discriminant values.

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

• LENGTH_CHECK Check that there is a matching component for each component of an array, in the case of array assignments, type conversions, and logical operators for arrays of boolean components.

• RANGE_CHECK Check that a value satisfies a range constraint. Also, for the elaboration of a subtype indication, check that the constraint (if present) is compatible with the type mark. Also, for an aggregate, check that an index or discriminant value belongs to the corresponding subtype. Finally, check for any constraint checks performed by a generic instantiation.

The following checks correspond to situations in which the exception NUMERIC_ERROR is raised. The only allowed names in the corresponding pragmas are names of numeric types.

• DIVISION_CHECK Check that the second operand is not zero for the operations /, rem and mod.

• OVERFLOW_CHECK Check that the result of a numeric operation does not overflow.

The following check corresponds to situations in which the exception PROGRAM_ERROR is raised. The only allowed names in the corresponding pragmas are names denoting task units, generic units, or subprograms.

• ELABORATION_CHECK When either a subprogram 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.

The following check corresponds to situations in which the exception STORAGE_ERROR is raised. The only allowed names in the corresponding pragmas are names denoting access types, task units, or subprograms.

• STORAGE_CHECK Check that execution of an allocator does not require more space than is available for a collection. Check that the space available for a task or subprogram has not been exceeded.

If an error situation arises in the absence of the corresponding run-time checks, the execution of the program is erroneous (the results are not defined by the language).

Examples:

    pragma SUPPRESS(RANGE_CHECK);
    pragma SUPPRESS(INDEX_CHECK, ON => TABLE); 

Notes:

For certain implementations, it may be impossible or too costly to suppress certain checks. The corresponding SUPPRESS pragma can be ignored. Hence, the occurrence of such a pragma within a given unit does not guarantee that the corresponding exception will not arise; the exceptions may also be propagated by called units.

References: access type 3.8, access value 3.8, activation 9.3, aggregate 4.3, allocator 4.8, array 3.6, attribute 4.1.4, block statement 5.6, collection 3.8, compatible 3.3.2, component of an array 3.6, component of a record 3.7, composite type 3.3, constraint 3.3, constraint_error exception 11.1, declarative part 3.9, designate 3.8, dimension 3.6, discrete range 3.6, discriminant 3.7.1, discriminant constraint 3.7.2, elaboration 3.1 3.9, erroneous 1.6, error situation 11, expanded name 4.1.3, generic body 11.1, generic instantiation 12.3, generic unit 12, identifier 2.3, index 3.6, index constraint 3.6.1, indexed component 4.1.1, null access value 3.8, numeric operation 3.5.5 3.5.8 3.5.10, numeric type 3.5, numeric_error exception 11.1, object 3.2, operation 3.3.3, package body 7.1, package specification 7.1, pragma 2.8, program_error exception 11.1, program unit 6, propagation of an exception 11.4, range constraint 3.5, record type 3.7, simple name 4.1, slice 4.1.2, subprogram 6, subprogram body 6.3, subprogram call 6.4, subtype 3.3, subunit 10.2, task 9, task body 9.1, task type 9.1, task unit 9, type 3.3, type mark 3.3.2