Re: Detecting uninitialized subroutine argument used as array bound of another argument

mecej4 wrote:
The short program below is a digest of an error in a much more complex and
larger program:

1 program test
2 implicit none
3 integer ia,nmax
4 dimension ia(10)
5 c
6 c Suppose the next line is left out by mistake
7 c nmax = 10
8 c
9 call sub(ia,nmax)
10 end
11 subroutine sub(ia,nmax)
12 implicit none
13 integer nmax,ia(nmax),i
14 do i=1,10
15 ia(i)=i
16 end do
17 return
18 end

The bug is the commented out Line-7. There are features in the algorithm of
the large program which necessitate using an upper limit other than 'nmax'
for the DO loop on Line-14.

My question is not about how to fix the bug, but as to what one may expect
from a compiler that provides facilities for subscript checking and, even
better, with facilities for trapping usage of uninitialized variables.

Here are the outputs from a number of different compilers. Which, in your
opinion, is the most helpful message?

....

Well, clearly the first that diagnosed the _exact_ problem would "win" on some counts.

All, however, correctly diagnose the problem in bounds sufficiently it shouldn't take but a minute or so to figure out what is wrong. Where the initialization failed to occur or what it should have been, of course, is potentially more problematic in a large, complex code, but the root cause is pretty straightforward to ascertain in these cases.

The problem arises in the potential case of having an uninitialized memory location that is interpretable as a large positive integer such that the array reference _is_ in bounds rather than in this case where it is large and negative so it also is caught as well a the zero-initialized memory cases.

Out of curiousity, what happens with that compiler if the main program and subroutine are compiled in separate files and then linked?

--
.

Relevant Pages