/UNDEF (which implies /CHECK) causes FTN95 to plant code to check that a variable or array element used in the circumstances described below has been previously given a value.
/UNDEF causes extra code to be planted for a name or array element appearing in the following circumstances:
as the right hand side of a non-character assignment,
in arithmetic expressions involving + - / * or **,
in relational expressions involving .NE. .EQ. etc.,
in logical expressions involving .AND. .OR. etc.,
as an array subscript,
as a substring expression,
as the argument to an ISO standard intrinsic function such as SIN, COS etc.,
as the expression used within a logical or arithmetic IF statement.
/FULL_UNDEF (also called /CHECKMATE) is like /UNDEF but also INTENT(OUT) arguments are initialised as undefined on entry to a procedure and by default character variables are initialised as undefined.
All local static variables are predefined to an undefined value. This value has HEX 80 in every byte. Routines compiled with /CHECK also clear their dynamic variables to this value on entry to the routine. This value is treated as undefined by the symbolic debugger. An undefined integer has one of the following values:
|
INTEGER (KIND=1) |
-128 |
|
INTEGER (KIND=2) |
-32640 |
|
INTEGER (KIND=3) |
Z'80808080' |
In rare cases, most likely when using integer data, the undefined integer value may be intended by the programmer and the use of /UNDEF will cause a spurious error to be reported. In this case, all that can be done is to compile the program unit(s) in question without /UNDEF. Note that:
The use of /UNDEF causes a significant run-time execution speed penalty.
It is necessary to compile the main program with this option if uninitialised common blocks are to be set appropriately.
For 64 bit programming, /UNDEF has not been implemented for variables that are initialised in BLOCK DATA.