- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Fortran subroutine dummy arguments mismatch ca...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-19-2007 09:17 AM
тАО04-19-2007 09:17 AM
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-19-2007 10:47 AM
тАО04-19-2007 10:47 AM
SolutionThere 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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-19-2007 12:24 PM
тАО04-19-2007 12:24 PM
Re: Fortran subroutine dummy arguments mismatch calling arguments
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
Archie
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-19-2007 01:03 PM
тАО04-19-2007 01:03 PM
Re: Fortran subroutine dummy arguments mismatch calling arguments
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-19-2007 04:42 PM
тАО04-19-2007 04:42 PM
Re: Fortran subroutine dummy arguments mismatch calling arguments
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-20-2007 02:45 AM
тАО04-20-2007 02:45 AM
Re: Fortran subroutine dummy arguments mismatch calling arguments
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-20-2007 03:35 AM
тАО04-20-2007 03:35 AM
Re: Fortran subroutine dummy arguments mismatch calling arguments
> "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, ...