Re: Several questions about character C binding

glen herrmannsfeldt wrote:
Steve Lionel wrote:

Where this poses a problem is in your desire to extend BIND(C) to
accommodate the IA-32 Windows STDCALL mechanism. If you somehow tell
the compiler to use STDCALL, then the external name it generates for
the call depends on the actual number of arguments pushed on the
stack, including any "hidden" arguments. But you have to use some
mechanism outside the standard to do this, so the standard no longer

For x86, there are calling conventions where the caller pops the
stack, and those where the callee pops the stack. The latter
case requires that the callee know the number of arguments.

I'll be honest and say that I can't get too worked up over trying to
ensure consistent behavior with BIND(C) and STDCALL, noting that not
only do you have to use a method outside the standard to get STDCALL
in ifort, but you also have to do so in the C compiler of your
choice. I'd go further and say that even if the Fortran compiler
defaulted to STDCALL (as CVF did), a BIND(C) routine would be
reasonably assumed to imply the C mechanism and that an attempt to
force it to use STDCALL should either be an error or be ignored. I
haven't discussed this with the rest of the team yet, but I will.

C varargs routines are pretty much incompatible with STDCALL, as
the number of arguments to pop is not known. ANSI C (unlike K&R C)
requires that varargs (routines with a variable number of arguments)
be specifically declared, and allows a different calling convention
to be used. Even though it is allowed, it is not usually done.

So yes, I would be very surprised to see a C compiler with STDCALL
as its default calling convention.

Not likely but the main reason why STDCALL (PASCAL) exists on Windows is because the OS API wasn't originally written in C. The only think I care about is being able to call the OS API, whatever language it is written in.

-- glen


Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:

Support the Original G95 Project:
Support the GNU GFortran Project:

If you want to do the impossible, don't hire an expert because he knows it can't be done.

-- Henry Ford

Relevant Pages

  • Re: calling convention stdcalll and cdecl call
    ... compatibility with existing stdcall code. ... Just as a C99 compiler isn't compatible with K&R code. ... An authoritative definition of what registers must be preserved ...
  • Re: calling convention stdcalll and cdecl call
    ... variadic functions. ... Any "extension" to the existing stdcall convention which breaks ... of compiler, and there doesn't even have to be one involved. ... and the same calling convention would still apply. ...
  • Re: calling convention stdcalll and cdecl call
    ... int __stdcall find(int what, ... ... than the caller, ... stdcall calling convention (one currently supported by VC compiler) ... I'm not sure what RVO has to do with anything. ...
  • Re: calling convention stdcalll and cdecl call
    ... Yet the first conclusion still holds -- it's not possible for any variadic stdcall to guarantee compatibility with existing stdcall code. ... An authoritative definition of what registers can be clobbered by ... But name mangling and such have always been subject to change between compiler versions. ...
  • Re: calling convention stdcalll and cdecl call
    ... int __stdcall find(int what, ... ... one) compared to cdecl. ... with fixed number and types of args: with cdecl the function needs to return to the caller to have the stack area used for arguments deallocated. ... Which might matter when that area is large -- it's not an optimization that I know any compiler to do, and it's only applicable in some corner cases, but it is an optimization that is available with stdcall, and not with cdecl. ...