Problem With Optional Parameters

To check all calls in a larger project, I copy all Fortran files together into one file for compilation. In case of an optional parameter I got a fatal error: error 326 - SUBROUTINE GETANGLE has been called with too few arguments. I made a small example:

    SUBROUTINE CALLER1 ()
    IMPLICIT NONE
    REAL*8 Phi, Omega, Kappa
    INTEGER iAerial
    CALL getAngle (Phi, Omega, Kappa, iAerial)
    RETURN 
    END

    SUBROUTINE CALLER2 ()
    IMPLICIT NONE
    REAL*8 Phi, Omega, Kappa
    CALL getAngle (Phi, Omega, Kappa)
    RETURN 
    END

    SUBROUTINE getAngle (Phi, Omega, Kappa, iAerial)  

    IMPLICIT NONE
    Real*8,  INTENT(OUT) :: Phi, Omega, Kappa
    INTEGER, OPTIONAL    :: iAerial

    IF (PRESENT(iAerial)) GOTO 10

    Phi   = 1.0D0
    Omega = 1.0D0
    Kappa = 1.0D0
    RETURN

 10 Phi   = 2.0D0
    Omega = 2.0D0
    Kappa = 2.0D0
    RETURN
    END SUBROUTINE getAngle

This provides just a worning: warning 673 - SUBROUTINE GETANGLE has been called with too few arguments If I change the sequence of the subroutines it works o.k.

Erwin

I guess that you need an interface for each call to GETANGLE.

Try putting them in a module.

In the Intel Fortran manual I found now:

'To call a procedure that has an optional argument, you must use an explicit interface.'

It would be nice to have such a hint as well in FTN95.

BTW: Practically my routine works fine without INTERFACE as long as I compile it it different files.

I have made a note that FTN95 needs to issue a warning or error report in this context; perhaps a warning but an error when /iso is applied.

Quoted from EKruck BTW: Practically my routine works fine without INTERFACE as long as I compile it it different files.

It does so because of a coincidence: the optional argument that is missing in the call is the [u:cdbbbd5fb7]last[/u:cdbbbd5fb7] argument, and the compiler pushes arguments on the stack in right-to-left order.

If you have a non-terminal optional argument absent in a call, your program will most likely crash or misbehave otherwise if you do not provide an interface. That an interface is required is one of the rules of the Fortran 95 and later standards.

I have had a further look at this and I don't see how FTN95 can do any better than what it does now.

In theory external subprograms are independently compiled (without any external knowledge). So the caller has no knowledge that the called subroutine has optional arguments.

When the various subprograms are in the same file then FTN95 does the best it can but the ordering of the subprograms will determine the outcome.

I agree with Paul on this issue.

We users often wish for certain features to make our program development easier and to help us catch bugs early, but in some cases these wishes cannot be fulfilled. That they are unreasonable/unimplementable becomes evident only upon deeper study of the Fortran standard and implementation issues.

For many program errors, the standard does not require the compiler to detect those errors -- these errors are the programmer's responsibility. For other program errors, the standard specifies 'constraints', in which case a compiler is required to detect the error.

I've found calling with too many arguments can be benign, but calling with too few (i.e. the call has 3 but the subroutine requires 4) will get you in trouble. Something about how the stack is handled in the routine and also back in the caller.

As well as not having a proper reference pointer to the data!