H.1 Pragma Normalize_Scalars

danger

This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue

1

This pragma ensures that an otherwise uninitialized scalar object is set to a predictable value, but out of range if possible.

1.a

discussion

The goal of the pragma is to reduce the impact of a bounded error that results from a reference to an uninitialized scalar object, by having such a reference violate a range check and thus raise Constraint_Error.

Syntax

2

The form of a pragma Normalize_Scalars is as follows:

3

pragma Normalize_Scalars;

Post-Compilation Rules

4

Pragma Normalize_Scalars is a configuration pragma. It applies to all compilation_units included in a partition.

Documentation Requirements

5/2

If a pragma Normalize_Scalars applies, the implementation shall document the implicit initial values for scalar subtypes, and shall identify each case in which such a value is used and is not an invalid representation.

5.a/2

note

Documentation Requirement: If a pragma Normalize_Scalars applies, the implicit initial values of scalar subtypes shall be documented. Such a value should be an invalid representation when possible; any cases when is it not shall be documented.

5.b

note

To be honest: It's slightly inaccurate to say that the value is a representation, but the point should be clear anyway.

5.c

discussion

By providing a type with a size specification so that spare bits are present, it is possible to force an implementation of Normalize_Scalars to use an out of range value. This can be tested for by ensuring that Constraint_Error is raised. Similarly, for an unconstrained integer type, in which no spare bit is surely present, one can check that the initialization takes place to the value specified in the documentation of the implementation. For a floating point type, spare bits might not be available, but a range constraint can provide the ability to use an out of range value.

5.d

note

If it is difficult to document the general rule for the implicit initial value, the implementation might choose instead to record the value on the object code listing or similar output produced during compilation.

Implementation Advice

6/2

Whenever possible, the implicit initial values for a scalar subtype should be an invalid representation (see 13.9.1).

6.a

discussion

When an out of range value is used for the initialization, it is likely that constraint checks will detect it. In addition, it can be detected by the Valid attribute.

6.b/2

note

This rule is included in the documentation requirements, and thus does not need a separate summary item.

7

note

NOTE 1 The initialization requirement applies to uninitialized scalar objects that are subcomponents of composite objects, to allocated objects, and to stand-alone objects. It also applies to scalar out parameters. Scalar subcomponents of composite out parameters are initialized to the corresponding part of the actual, by virtue of 6.4.1.

8

note

NOTE 2 The initialization requirement does not apply to a scalar for which pragma Import has been specified, since initialization of an imported object is performed solely by the foreign language environment (see B.1).

9/5

note

NOTE 3 The use of pragma Normalize_Scalars in conjunction with Pragma Restrictions(No_Exceptions) can result in erroneous execution (see H.4).

9.a

discussion

Since the effect of an access to an out of range value will often be to raise Constraint_Error, it is clear that suppressing the exception mechanism could result in erroneous execution. In particular, the assignment to an array, with the array index out of range, will result in a write to an arbitrary store location, having unpredictable effects.