2.89 Pragma Initialize_Scalars

Syntax:

pragma Initialize_Scalars
  [ ( TYPE_VALUE_PAIR {, TYPE_VALUE_PAIR} ) ];

TYPE_VALUE_PAIR ::=
  SCALAR_TYPE => static_EXPRESSION

SCALAR_TYPE :=
  Short_Float
| Float
| Long_Float
| Long_Long_Flat
| Signed_8
| Signed_16
| Signed_32
| Signed_64
| Unsigned_8
| Unsigned_16
| Unsigned_32
| Unsigned_64

This pragma is similar to Normalize_Scalars conceptually but has two important differences.

First, there is no requirement for the pragma to be used uniformly in all units of a partition. In particular, it is fine to use this just for some or all of the application units of a partition, without needing to recompile the run-time library. In the case where some units are compiled with the pragma, and some without, then a declaration of a variable where the type is defined in package Standard or is locally declared will always be subject to initialization, as will any declaration of a scalar variable. For composite variables, whether the variable is initialized may also depend on whether the package in which the type of the variable is declared is compiled with the pragma.

The other important difference is that the programmer can control the value used for initializing scalar objects. This effect can be achieved in several different ways:

• * At compile time, the programmer can specify the invalid value for a particular family of scalar types using the optional arguments of the pragma.

  The compile-time approach is intended to optimize the generated code for the pragma, by possibly using fast operations such as memset. Note that such optimizations require using values where the bytes all have the same binary representation.

• * At bind time, the programmer has several options:
  • * Initialization with invalid values (similar to Normalize_Scalars, though for Initialize_Scalars it is not always possible to determine the invalid values in complex cases like signed component fields with nonstandard sizes).
  • * Initialization with high values.
  • * Initialization with low values.
  • * Initialization with a specific bit pattern.

  See the GNAT User’s Guide for binder options for specifying these cases.

  The bind-time approach is intended to provide fast turnaround for testing with different values, without having to recompile the program.

• * At execution time, the programmer can specify the invalid values using an environment variable. See the GNAT User’s Guide for details.

  The execution-time approach is intended to provide fast turnaround for testing with different values, without having to recompile and rebind the program.

Note that pragma Initialize_Scalars is particularly useful in conjunction with the enhanced validity checking that is now provided in GNAT, which checks for invalid values under more conditions. Using this feature (see description of the `-gnatV' flag in the GNAT User’s Guide) in conjunction with pragma Initialize_Scalars provides a powerful new tool to assist in the detection of problems caused by uninitialized variables.

Note: the use of Initialize_Scalars has a fairly extensive effect on the generated code. This may cause your code to be substantially larger. It may also cause an increase in the amount of stack required, so it is probably a good idea to turn on stack checking (see description of stack checking in the GNAT User’s Guide) when using this pragma.