Inconsistent number of arguments not caught by compiler?

[Intel_C_Intel]

Apparently 8.0 at least does not catch it when the number of arguments in the calling program does not match the number of arguments in the target routine when they are in the same source file. CVF use to do this. Is there a switch I'm missing?

Not real serious, but if you don't catch it wild things can happen and Visual Studio can crash unexpectedly.

[TimP]

We have discussed this several times on the forum. The compiler developers consider the compile-time argument cross-check unnecessary, in view of the availability of MODULE and INTERFACE BLOCK syntax, either ofwhich would force the check. Compile option -C may enable it to be caught at run time.

[Steven_L_Intel1]

I would not say that the developers consider this check unnecessary. However, with the switch to the Intel "back end", some things that were easy to do in CVF, such as run through all the intermediate language and look for inconsistencies such as this, are extremely diffiicult to do with the Intel "back end".

We are looking at alternative solutions to improve argument consistency checking for future releases. As Tim mentions, use of explicit interfaces can catch these and many other types of errors.

[Intel_C_Intel]

OK, so it's not a bug, it's a feature.

So every time I write a fortran subroutine I should write a set of interface statements? I then have to worry about using them all the time, maintaining them as things change? Give me a break, that's a step backwards as far as I'm concerned. How hard can it be for the compiler to count arguments as it makes the first pass? That's like saying the CALL and SUBROUTINE stastements are obolete and we should requirereplacing them with multiple statements. Compliers are supposed to make things easier, not harder than needed.

It's not a big issue with me, it's just that I didn't look for that kind of problem the first time it hit me, since I "knew" from past experience the compiler would have caught it. Instead one gets wierd and wonderful activity leading usually to advising us to report the studio.net crashes to MS.

I know interface statements can be needed when for some reason you need to tell a routine what kind of stuff to expect, variable arguments, etc. although I don't think it should be necessary;the compiler should take that burden off us us. But if it can find an inappropriate number of argumentswhen a set of interface statements exists, it's hard to see why parsing a subroutine call for # args is so much harder...

[Jugoslav_Dujic]

It's been discussed before, but I don't see Tim and Steve mentined it here explicitly.

CVF used stdcall convention, which has @n appended at the end, while IVF uses cdecl, which does not have that decoration, allowing number of arguments mismatch. The change was introducedpartly because many people wanted to compile old (illegal) codes that abused mismatchin number of arguments or CHARACTER/BYTE type mismatch. (Personally, I prefer it the CVF way but...). With cdecl, the mismatch is usually harmless (providing missing arguments are not accessed) due to the method of stack handling.

So, if you want the old way, use "CVF" calling convention in Project Settings. This is not a panacea, of course, because e.g. real/double precision mismatches willpass unnoticed.

INTERFACE blocks are not recommended way of providing explicit interface, because they're error-prone. Instead, MODULEs are recommended -- however, they cancause inconvenient"compilation cascades". There's also "C-style" "middle-way" (".h"+".cpp") that you provide only INTERFACEs within MODULEs or INCLUDE files, and routine bodies in external files -- that avoids compilation cascade, but requires you to maintain correct INTERFACEs (only in one place) and does not have all the advantages of MODULEs (such as data hiding/encapsulation).

Jugoslav