Detecting uninitialized subroutine argument used as array bound of another argument 
Author Message
 Detecting uninitialized subroutine argument used as array bound of another argument

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?

-- mecej4

___________________________________________________________
1.
Reference to undefined variable NMAX
Program terminated by fatal error
In SUB, line 11 of tst.f
Called by TEST, line 9 of tst.f
Aborted

2.
Subscript out of range for array ia (subscript: 1, declared size: 0).
 Error occurs at or near line 15 of sub_
 Called from or near line 9 of MAIN__

3.
 ******  fortran RUN-TIME SYSTEM  ******
Subscript out of range. Location:  line 15 column 13 of 'tst.f'
Subscript number 1 has value 1 in array 'IA'
Aborted

4.
At line 15 of file tst.f
Traceback: (Innermost first)
   Called from line 9 of file tst.f
Fortran runtime error: Array element out of bounds: 1 in (1:0), dim=1

5.
forrtl: severe (408): fort: (2): Subscript #1 of the array IA has value 1
which is greater than the upper bound of -858993460



Fri, 16 Apr 2010 21:48:16 GMT  
 Detecting uninitialized subroutine argument used as array bound of another argument
Quote:

> 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?

--



Fri, 16 Apr 2010 21:56:06 GMT  
 Detecting uninitialized subroutine argument used as array bound of another argument
As if by magic, dpb appeared !

Quote:

>> 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.

Hmmmmm, I'd be willing to argue with it diagnosing the _exact_ problem:

Reference to undefined variable NMAX
Program terminated by fatal error
In SUB, line 11 of tst.f
Called by TEST, line 9 of tst.f
Aborted

Make that read

In SUB, line 13 of tst.f

and I would be totally happy

Ian



Fri, 16 Apr 2010 22:40:50 GMT  
 Detecting uninitialized subroutine argument used as array bound of another argument

Quote:

> As if by magic, dpb appeared !


>>> 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.

> Hmmmmm, I'd be willing to argue with it diagnosing the _exact_ problem:

> Reference to undefined variable NMAX
> Program terminated by fatal error
> In SUB, line 11 of tst.f
> Called by TEST, line 9 of tst.f
> Aborted

> Make that read

> In SUB, line 13 of tst.f

> and I would be totally happy

I'd be perfectly happy with the existing diagnostic and location -- it
pointed to the correct variable by name where it is in the argument list
  as being an undefined variable.  Don't see any real advantage in the
"waiting" until it is in the array dimensioning clause as being any more
helpful, personally.

--



Fri, 16 Apr 2010 23:11:18 GMT  
 Detecting uninitialized subroutine argument used as array bound of another argument

Lahey LF95 for Windows with debug options:
-chk(a,e,s,u,x) -chkglobal -g  -pca -stchk -trace -nzero -o0 -trap diou

Subscript out of range for array ia (subscript: 1, declared size: 0).
 Error occurs at or near line 15 of _sub_
 Called from or near line 9 of _MAIN__

 Silverfrost FTN95 for Windows with debug options:
 /DEBUG /CHECK /FULL_UNDEF /FULL_DEBUG

Run-time Error
 *** Error  112, Reference to undefined variable,
     array element or function result (/UNDEF)
 SUB -  in file undef.for at line 10 [+003c]
 TEST -  in file undef.for at line 9 [+0041]

-|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?
-|
-|-- mecej4
-|
-|___________________________________________________________
-|1.
-|Reference to undefined variable NMAX
-|Program terminated by fatal error
-|In SUB, line 11 of tst.f
-|Called by TEST, line 9 of tst.f
-|Aborted
-|
-|2.
-|Subscript out of range for array ia (subscript: 1, declared size: 0).
-| Error occurs at or near line 15 of sub_
-| Called from or near line 9 of MAIN__
-|
-|3.
-| ******  FORTRAN RUN-TIME SYSTEM  ******
-|Subscript out of range. Location:  line 15 column 13 of 'tst.f'
-|Subscript number 1 has value 1 in array 'IA'
-|Aborted
-|
-|4.
-|At line 15 of file tst.f
-|Traceback: (Innermost first)
-|   Called from line 9 of file tst.f
-|Fortran runtime error: Array element out of bounds: 1 in (1:0), dim=1
-|
-|5.
-|forrtl: severe (408): fort: (2): Subscript #1 of the array IA has value 1
-|which is greater than the upper bound of -858993460



Fri, 16 Apr 2010 23:32:46 GMT  
 Detecting uninitialized subroutine argument used as array bound of another argument

Quote:


>> As if by magic, dpb appeared !


>>>> 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.

>> Hmmmmm, I'd be willing to argue with it diagnosing the _exact_ problem:

>> Reference to undefined variable NMAX
>> Program terminated by fatal error
>> In SUB, line 11 of tst.f
>> Called by TEST, line 9 of tst.f
>> Aborted

>> Make that read

>> In SUB, line 13 of tst.f

>> and I would be totally happy

> I'd be perfectly happy with the existing diagnostic and location -- it
> pointed to the correct variable by name where it is in the argument list
>   as being an undefined variable.  Don't see any real advantage in the
> "waiting" until it is in the array dimensioning clause as being any more
> helpful, personally.

> --

Since the notion of INTENT did not exist in Fortran-77, there would be
nothing wrong in 'nmax' being undefined at subprogram invocation -- it
could simply be an output variable. However, the compiler could note
that 'nmax' was used in declaring an array and, therefore, has to be
defined at subroutine entry. In order to avoid issuing spurious messages,
the compiler would have to parse all the declarations and infer the
`intent' of the variable.

As with other exceptions, the question is whether to emit an error message
when the existence of an uninitialized variable (expected to be used at
some later time) within scope is first recognized, or when its value is
asked for for the first time.

-- mecej4



Sat, 17 Apr 2010 00:25:02 GMT  
 Detecting uninitialized subroutine argument used as array bound of another argument

Quote:


...
>> I'd be perfectly happy with the existing diagnostic and location -- it
>> pointed to the correct variable by name where it is in the argument list
>>   as being an undefined variable.  Don't see any real advantage in the
>> "waiting" until it is in the array dimensioning clause as being any more
>> helpful, personally.
...
> Since the notion of INTENT did not exist in Fortran-77, there would be
> nothing wrong in 'nmax' being undefined at subprogram invocation -- it
> could simply be an output variable. However, the compiler could note
> that 'nmax' was used in declaring an array and, therefore, has to be
> defined at subroutine entry. ...

What does the same compiler do if nmax _isn't_ used for the array
dimensions?

--



Sat, 17 Apr 2010 00:33:06 GMT  
 Detecting uninitialized subroutine argument used as array bound of another argument
Quote:



>>> As if by magic, dpb appeared !


>>>>> 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.

>>> Hmmmmm, I'd be willing to argue with it diagnosing the _exact_ problem:

>>> Reference to undefined variable NMAX
>>> Program terminated by fatal error
>>> In SUB, line 11 of tst.f
>>> Called by TEST, line 9 of tst.f
>>> Aborted

>>> Make that read

>>> In SUB, line 13 of tst.f

>>> and I would be totally happy
>> I'd be perfectly happy with the existing diagnostic and location -- it
>> pointed to the correct variable by name where it is in the argument list
>>   as being an undefined variable.  Don't see any real advantage in the
>> "waiting" until it is in the array dimensioning clause as being any more
>> helpful, personally.

>> --

> Since the notion of INTENT did not exist in Fortran-77, there would be
> nothing wrong in 'nmax' being undefined at subprogram invocation -- it
> could simply be an output variable. However, the compiler could note
> that 'nmax' was used in declaring an array and, therefore, has to be
> defined at subroutine entry. In order to avoid issuing spurious messages,
> the compiler would have to parse all the declarations and infer the
> `intent' of the variable.

INTENT isn't really much help here.  An INTENT(IN) argument
does not have to be defined on subroutine entry.  The only rule is that
it can't be redefined or become undefined during subroutine execution.
An INTENT(INOUT) argument always has to be definable, but it doesn't
have to de defined on entry nor become defined before the return.
INTENT(OUT) only requires that the argument become defined before it
is referenced within the subroutine.

INTENT is much closer to a comment than to a statement.  When combined
with modules a compiler can catch obvious mismatches in arguments.
But it's not much help with errors caused by control flow skipping
variable initialization.

It's really up to the programmer to avoid using undefined variables.

Dick Hendrickson

- Show quoted text -

Quote:
> As with other exceptions, the question is whether to emit an error message
> when the existence of an uninitialized variable (expected to be used at
> some later time) within scope is first recognized, or when its value is
> asked for for the first time.

> -- mecej4



Sat, 17 Apr 2010 00:40:30 GMT  
 Detecting uninitialized subroutine argument used as array bound of another argument

Quote:



> ...
>>> I'd be perfectly happy with the existing diagnostic and location -- it
>>> pointed to the correct variable by name where it is in the argument list
>>>   as being an undefined variable.  Don't see any real advantage in the
>>> "waiting" until it is in the array dimensioning clause as being any more
>>> helpful, personally.
> ...
>> Since the notion of INTENT did not exist in Fortran-77, there would be
>> nothing wrong in 'nmax' being undefined at subprogram invocation -- it
>> could simply be an output variable. However, the compiler could note
>> that 'nmax' was used in declaring an array and, therefore, has to be
>> defined at subroutine entry. ...

> What does the same compiler do if nmax _isn't_ used for the array
> dimensions?

> --

Nothing of interest, as in that case nmax becomes just another uninitialized
variable. Since it is not used elsewhere in the subroutine, nothing happens
at all.

If it is used in an expression or as the upper limit of the DO loop, it is
flagged -- "Reference to undefined variable NMAX".

-- mecej4



Sat, 17 Apr 2010 00:52:04 GMT  
 Detecting uninitialized subroutine argument used as array bound of another argument

Quote:



<< CUT >>
>> Since the notion of INTENT did not exist in Fortran-77, there would be
>> nothing wrong in 'nmax' being undefined at subprogram invocation -- it
>> could simply be an output variable. However, the compiler could note
>> that 'nmax' was used in declaring an array and, therefore, has to be
>> defined at subroutine entry. In order to avoid issuing spurious messages,
>> the compiler would have to parse all the declarations and infer the
>> `intent' of the variable.

> INTENT isn't really much help here.  An INTENT(IN) argument
> does not have to be defined on subroutine entry.  The only rule is that
> it can't be redefined or become undefined during subroutine execution.
> An INTENT(INOUT) argument always has to be definable, but it doesn't
> have to de defined on entry nor become defined before the return.
> INTENT(OUT) only requires that the argument become defined before it
> is referenced within the subroutine.

> INTENT is much closer to a comment than to a statement.  When combined
> with modules a compiler can catch obvious mismatches in arguments.
> But it's not much help with errors caused by control flow skipping
> variable initialization.

> It's really up to the programmer to avoid using undefined variables.

>{*filter*} Hendrickson

Thanks for your helpful explanations as to the intent of INTENT.

-- mecej4



Sat, 17 Apr 2010 01:28:30 GMT  
 Detecting uninitialized subroutine argument used as array bound of another argument

Quote:




>> ...
>>>> I'd be perfectly happy with the existing diagnostic and location -- it
>>>> pointed to the correct variable by name where it is in the argument list
>>>>   as being an undefined variable.  Don't see any real advantage in the
>>>> "waiting" until it is in the array dimensioning clause as being any more
>>>> helpful, personally.
>> ...
>>> Since the notion of INTENT did not exist in Fortran-77, there would be
>>> nothing wrong in 'nmax' being undefined at subprogram invocation -- it
>>> could simply be an output variable. However, the compiler could note
>>> that 'nmax' was used in declaring an array and, therefore, has to be
>>> defined at subroutine entry. ...
>> What does the same compiler do if nmax _isn't_ used for the array
>> dimensions?

>> --
> Nothing of interest, as in that case nmax becomes just another uninitialized
> variable. Since it is not used elsewhere in the subroutine, nothing happens
> at all.

> If it is used in an expression or as the upper limit of the DO loop, it is
> flagged -- "Reference to undefined variable NMAX".

OK, so it does sense the use but (apparently) relate the error back to
the first location as presumed it would as otherwise it would be a quite
blatant bug in the compiler -- perhaps could be at the point of the
actual reference as Ian would like but I personally still think it's as
useful either place...

--



Sat, 17 Apr 2010 02:39:57 GMT  
 Detecting uninitialized subroutine argument used as array bound of another argument

As if by magic, dpb appeared !

Quote:

> OK, so it does sense the use but (apparently) relate the error back to
> the first location as presumed it would as otherwise it would be a quite
> blatant bug in the compiler -- perhaps could be at the point of the
> actual reference as Ian would like but I personally still think it's as
> useful either place...

Oh - it's definitely useful> However I think it can be improved, that
was all my point,

Ian



Sat, 17 Apr 2010 19:47:24 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. A problem about using array as subroutine argument in F77

2. Subroutine arguments: arrays vs array slices

3. how to use an array as subroutine arguments?

4. declaring array arguments in subroutines

5. Finding the size of array arguments in subroutines

6. Q: detecting overlapping array arguments

7. passing array arguments to subroutines

8. Allocatable arrays as arguments to subroutine questions

9. array/scalar subroutine arguments

10. Detecting Array Out of Bounds in DVF

11. Assumed-shape array bounds in subroutine

12. Getting Array bound and passing to subroutine

 

 
Powered by phpBB® Forum Software