topic Re: Fortran subroutine dummy arguments mismatch calling arguments in Operating System - OpenVMS

Fortran subroutine dummy arguments mismatch calling arguments

Patrick Grealy — Thu, 19 Apr 2007 16:17:37 GMT

Hi,

I have always thought that in Fortran if a calling statement used a different number of arguments than the number of dummy arguments in the subroutine that a compiler warning and/or fatal execution error occurred. However, I was suprised to learn recently that this is not the case.

If the calling statement has two arguments and the subroutine has three dummy arguments there is no compiler warning nor execution error unless the subroutine tries to use dummy arg 3; then there is an execution error. If the calling statement has three arguments and the subroutine has two dummy arguments there is no warning and no execution error.

Our system is OpenVMS 7.3-1 and we have HP Fortran V7.6-3276 installed. I have looked in the documentation and found the compiler switch "/warn=argument_checking" that should help quite a bit. It will force compilation warnings when the calling module and subroutine are "compiled together" and argument counts are mismatched. However, if the subroutine is in a linked library this would not help.

I have a couple of questions. Is there some other option that I am overlooking? Did this behavior change in transitioning from Fortran 77(DEC) to Fortran 95(HP)? Finally, is there a way I could make our Fortran installation default to "/warn=argument_checking"?

Thanks,
Pat Grealy

Re: Fortran subroutine dummy arguments mismatch calling arguments

Jess Goodman — Thu, 19 Apr 2007 17:47:43 GMT

My Fortran 77 V7.1-156 compiler does not output warnings for this even when using /WARNING=ARGUMENT_CHECKING.

There is an advantage to the default non-checking behaviour, at least for the case of an extra dummy argument in the subroutine. At our site we add new arguments to subroutines sometimes when we want to add new options to them. However so that we don't have to find and modify all old code that calls the subroutine the default behaviour stays the same if the new argument is missing. We use the DEC-extension IARGCOUNT intrinsic to check of the new argument was passed or not before using it. Of course this practice is not standard Fortran.

Just to make clear what the documentation means when it says /WARN=ARGUMENT_CHECKING only applies if the two routines are "compiled together". Either the two routines must be in the same source module, or if they are in separate modules they must be compiled with one command line that lists both source files with a + between them, as in:

$ F90 /WARN=ARGUMENT_CHECKING MAIN.F+SUB.F

This is one of the few cases in VMS where using a + instead of a , between two files in a list makes a difference.

Also you obviously can not use the qualifer /SEPARATE_COMPILE (normally that is only used when creating object libraries from one source module with mulitple routines).

Re: Fortran subroutine dummy arguments mismatch calling arguments

Arch_Muthiah — Thu, 19 Apr 2007 19:24:08 GMT

Hi Pat,

When an explicit interface is present between calling and called procedures, warning messages about argument mismatches are reported whether or not you specify -warn argument_checking.
Defining explicit interface such as INTERFACE ...END INTERFACE is available in F77?

Archunan

Re: Fortran subroutine dummy arguments mismatch calling arguments

John Gillings — Thu, 19 Apr 2007 20:03:47 GMT

Pat,

The behaviour has not changed. That's the way Fortran has been forever on VMS (indeed, many people have exploited the lack of argument checking to implement/hack variable argument lists). Excess arguments are always tolerated. See the OpenVMS calling standard to help understand why.

Fortran is showing its age! The issue here is the nature of the languge. Fortran originally compiled modules in complete isolation, so the compiler had to believe whatever you claimed about external objects, in particular argument lists. Over time some limited checking/enforcment features have been added.

If the compiler can see both modules at the same time, then /WARN=ARGUMENT_CHECKING is feasible. As Jess has explained that requires the routines to either be in the same source file, or the compiler parameters "added" with "+" rather than ",".
Although there is some capability for the linker to check argument lists, it's not widely used by compilers (and can cause trouble as there are many cases where argument lists can vary).

If you use Fortran modules, with interface definitions and the USE sttement to import modules, you can give the compiler the information it needs to check routine interfaces, without having to compile everything together. Note that this will require a fairly significant change in programming style. (some would say for the better, but others would say, if you want to code like that, switch to Pascal or Ada)

Re: Fortran subroutine dummy arguments mismatch calling arguments

Steven Schweda — Thu, 19 Apr 2007 23:42:32 GMT

(I hate to say it, but) A.M. probably has the
best answer here. You can put an INTERFACE
spec into a header file, and then INCLUDE
that file into the file with the subprogram
itself, and into the file where the
subprogram is invoked. The compiler will
check the subprogram definition or its
invocation against the included INTERFACE
spec, and complain as warranted.

My Fortran is extremely rusty, but a crude
example follows.

alp $ type A.FH
C Interface specification for function a( b, c)

interface
function a( b, c)
integer* 4 a
integer* 4 b
real* 8 c
end function
end interface

alp $ type A_SUB.FOR
C Useless function a( b, c), with explicit interface.

function a( b, c)

implicit none

include 'a.fh'

integer* 4 a
integer* 4 b
real* 8 c

a = b* c

end function

alp $ type A_MAIN.FOR
C Useless main program.

program a_main

implicit none

include 'a.fh'

integer* 4 x
integer* 4 y
real* 8 z

y = 3
z = 4.
x = a( y, z)

print *, " x = ", x

end

alp $ for A_SUB
alp $ for A_MAIN
alp $ link A_MAIN, A_SUB
alp $ run A_MAIN
x = 12

Try to use the function with a bad argument
list:

alp $ for B_MAIN

x = a( y)
..........^
%F90-E-ERROR, A non-optional actual argument must be present when invoking a pro
cedure with an explicit interface. [C]
at line number 15 in file ALP$DKA0:[SMS]B_MAIN.FOR;8

Forget to include the header file:

alp $ for C_MAIN

x = a( y, z)
..........^
%F90-E-ERROR, This name does not have a type, and must have an explicit type.
[A]
at line number 15 in file ALP$DKA0:[SMS]C_MAIN.FOR;2

Hardly an exhaustive test, but perhaps a fair
demonstration of the scheme. Note that with
IMPLICIT NONE (one of the best ideas ever),
no special compiler options are needed to
generate either of these complaints.

Re: Fortran subroutine dummy arguments mismatch calling arguments

Patrick Grealy — Fri, 20 Apr 2007 09:45:17 GMT

I guess my recollection is a little foggy and I must be thinking of the fatal execution error that occurs when code in a subroutine tries to use a dummy argument for which no actual argument was supplied.

Maybe my colleagues and I have become so skilled that instances of argument mismatches have become increasingly rare over the years and this problem has not attracted our attention! I will share these comments with them and suggest we adopt the /warn=argument_check usage.

We are a small group, set in our ways, and until I started investigating this behavior, had never been exposed to the "Interface" structure and some of the other more modern ideas expressed above. I do appreciate everyone's contribution here.

Pat G.

Re: Fortran subroutine dummy arguments mismatch calling arguments

Steven Schweda — Fri, 20 Apr 2007 10:35:30 GMT

> [...] had never been exposed to the
> "Interface" structure

It was news to me, too. I haven't done any
Fortran work since it was still FORTRAN, and
names longer than six characters were new and
exotic. I don't think that I'd ever seen a
message which started out "%F90-".

Looking around, it appears that my (old)
"header" files were confined to COMMON
declarations. (It's nice if everyone agrees
on what's in COMMON, too.) I always assumed
that "Fortran" had a bunch more modern
features than "FORTRAN", but I haven't needed
to deal with the stuff for a decade or so, so
I never learned any of the more modern stuff.
Maybe someday when everything else works
right, ...