Concept of "Undefined"

1.5.2 The Concept of "Undefined"

One of the fundamental concepts of the FORTRAN standard is the concept of "undefined." This is one of the most important concept, yet one of the most difficult to comprehend. Anyone who has studied FORTRAN has probably encountered the following sentence in a grammar book and has been puzzled by it.

When xx, variable yy is undefined.

At first glance, this may seem to mean that "a random number is assigned to yy," or that "the value is erased from memory," but that is not what this means. In most cases, the compiler is certain about what happens to yy in case of xx .

To understand this rather puzzling sentence, you need to consider who the documents of FORTRAN standard were written for. The FORTRAN standard is a document written for us programmers as well as for those who create the FORTRAN compilers. Therefore, this sentence was written so that it can be translated in two ways. For those who create compilers, the above sentence translates to

When xx, the memory area occupied by variable yy may be used.

To us programmers, this translates to

Since those creating compiler were told the above, what happens to yy is undefined.

If this sentence is taken as a message from "those who created" the compiler to "those who use" compilers, many will no doubt be indignant that "the creator should be so irresponsible that he doesn't know what happens!" Especially, one gets such an impression upon reading the grammar book that comes with the compiler. But keep in mind that a FORTRAN grammar book contains

rules for clarifying the responsibilities of both parties, those who create compilers and those who use them.

The opposite of "undefined" is "defined," a state in which the value is guaranteed by the standard. According to standard, variables that can be inquired in programs are limited to those "defined." A variable becomes "undefined" in the following cases.

When the variable is not defined
This is the most easy-to-understand case of "undefined." If a value is not assigned to a variable, obviously, there is no knowing what value the variable takes.

Some compilers initialize all variables (normally by assigning 0). In FORTRAN standard, the variable is "undefined," (hence, what to do is left up to the compiler), so such compilers are not going against the FORTRAN standard. However, this state is not guaranteed by the standard, and is a type of "dialect," so programs should not be written with this precondition when considerations are given to future applications of the programs in different compilers.

When you want to assign a value to a variable from the start, use the DATA statement. See example below.
After executing the RETURN or END statement in a subroutine
Variables used in subroutines become, with a few exceptions, "undefined" once the execution of the subroutine is over.

This may be a bit difficult to understand, but it means that when the same subroutine is called twice, in the second call, you cannot inquire on a variable that has been assigned a value in the first call, since there is no guarantee that the value has been saved.

See the following program, for example.
```
*------------ main program -----------

      DO 100 I=1, 100

        CALL BEAT

  100 CONTINUE

      END

*--------------------------------

      SUBROUTINE BEAT

      DATA N /0/

      SAVE



      N=N+1

      IF(N.EQ.10) THEN

        WRITE(6,*) ' I hate you !'

        N=0

      ENDIF

      END
```
This subroutine beat remembers the number of times (n) that is was called, and prints a message when it has been called 10 times.

Variable n is defined and given the value 0 using a DATA statement before beat is called. Every time beat is called, 1 is added to variable n. However, if it were not for the SAVE statement in line 9, the n again becomes undefined after the END statement in line 16, according to the FORTRAN standard.

The SAVE statement is a declaration ordering the program to keep the value of the variable in the subroutine after the end of execution. In a program such as this, in which the value of variable n must be kept to the next call in order for it to operate properly, the SAVE statement must always be included.

Depending on the compiler (or in most compilers), local variables in the subroutine are kept, but this also, is a "dialect.".

However, variables specified using the DATA statement do not become "undefined" even after the RETURN or END statement has been executed, unless the value is overwritten.

The glpget/glpset of the DCL can act as a bulletin board due to the DATA and SAVE statements. (See Section 1.5.4.)

When the SAVE statement is specified, the executed file size usually increases, but in many cases, the execution speed increases.
When different types of variables are associated
When different types of variables are associated using the EQUIVALENCE statement and one of the variables is defined, the other becomes undefined. For example, in the following program,
```
      INTEGER IX

      REAL    RX

      EQUIVALENCE (IX, RX)

      RX = 1.

      WRITE(6,*) IX

      END
```
when the floating-point variable rx is assigned, the value of the integer variable ix becomes undefined. Therefore, the WRITE statement inquiring on an undefined variable is grammatically incorrect.

In this case, though, ix has a "certain value." . However, since the expression format for integers and floating-point numbers are not the same for different compilers, what this "certain value" is cannot be predicted from FORTRAN standard. Hence, it is "undefined."

Therefore, the result of this program cannot be predicted from grammar, but it will, nonetheless. usually operate properly and output a "certain value." (See Section 1.5.4)