"I have come here for an argument, side 2"

[jirina]

I have just read Doctor Fortran's "I have come here for an argument, side 2" and I would like to ask (probably a very silly) question.

I have a code written in F77 with some Watcom Fortran extensions, and finally adjusted (some WF extensions removed and replaced by routines from IFPORT and other modules).

It quite often happens in my code that a subroutine is called with arguments which are modified inside the subroutine and the modified value is used by the caller, e.g.

call findObjectInX ( i )

subroutine findObjectInX ( i )
integer*4 i, iMax
logical*4 isObject
...
do while ( .NOT.isObjectAt(i) .AND. i.le.iMax )
i = i+1
enddo

return
end
(iMax is assigned a value somewhere in ... and isObjectAt does not modify i)

My feeling is that my code works well, or to be more precise, works as I would like it to, even though Steve's above mentioned post states that I should get a run-time error, because I don't have /assume:noprotect_constants defined in project's properties.

Could it be another compiler's option preventing my code from running into run-time errors? The command line reads:

/nologo /fpp /fixed /extend_source:132 /Qopenmp /fpscomp:general /warn:declarations /warn:unused /assume:byterecl /libs:static /threads /c /align:all /heap-arrays

I am sorry for a potentially silly question; I might be missing something or understanding the Steve's post incorrectly.

[TimP]

The problem Steve discusses occurs where you supply a constant rather than a variable in the CALL to a subroutine which uses the argument as INTENT(INOUT) (but in F77 style). You show a variable in the CALL, so there is no problem there. Use of the options /fpscomp and /extend_source may be undesirable, but it's not related.