| | | |
TOC -- / --.-- / --.--.-- | Index | Search | Syntax | Help

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)

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.

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

NOTES

(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);

| | | |
TOC -- / --.-- / --.--.-- | Index | Search | Syntax | Help

-- Email comments, additions, corrections, gripes, kudos, etc. to: