How to detect missing argument in subroutine

[jeremy_h]

We have old code that sometimes calls subroutines with the last argument missing. No doubt this is highly unrecommended, but CVF apparently creates stack space for the missing argument and then discards it during the return. IVF generates an access violation.

My question is, is it possible to detect whether the argument will generate an access violation before accessing it? If so, I could fix the code in the subroutine rather than in all the clients.

[jimdempseyatthecove · Accepted solution]

IVF has an option to check subroutine interfaces. This should be listed in your VS project properties (Configuration | Fortran | Diagnostics | Warn Routine Interfaces) or documented in IVF.

Depending on your version of IVF the option may be different. The older versions requires to options /gen-interfaces and /warn:interfaces. The newer versions use just /warn:interfaces.

You should use interfaces for these routines (place into module file as opposed to include file) and attributethe optional arg as OPTIONAL. This will keep you from having runtime surprises (crash, abnormal, or hidden behavior).

These interfaces could be stuck into a module already USE'd by all your clients. This way none of the client files need be touched.

Jim Dempsey

[mecej4]

If you consider the implications of calling in Fortran 77 a subroutine with fewer than the required number of arguments, you might come to look upon a flagged access violation as a good thing.

Consider this example:

[fxfortran]      program badcall
      integer a,b,c
      a=2
      b=3
      call sub(a,b)
      end

      subroutine sub(a,b,c)
      integer a,b,c
      c=a+b
      return
      end
[/fxfortran]

Since no address for the argument c is pushed on to the stack at the calling point, the subroutine puts the sum of a and b into an arbitrary address. If the address happens to be write protected, you get an access violation. If not, some variable gets clobbered. Thus, the result of calling the subroutine is unpredictable; worse, such errors can go undetected for a long time.

Furthermore, if the STDCALL convention is used, the number of arguments popped is different from the number of arguments pushed, so the stack gets messed up, again with unpredictable (but almost always bad) consequences.

Such code is illegal and you should take the time to fix it.

[jeremy_h]

I appreciate the responses - thanks to all, very helpful.