Re: Several questions about character C binding



glen herrmannsfeldt wrote:
Steve Lionel wrote:
(snip)

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
applies.


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: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

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 ...
    (microsoft.public.vc.language)
  • 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. ...
    (microsoft.public.vc.language)
  • 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. ...
    (microsoft.public.vc.language)
  • 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. ...
    (microsoft.public.vc.language)
  • Re: Win32 API and gfortran
    ... STDCALL routines and their global symbols have the @n suffix. ... based on the number and type of arguments the routine expects. ... you have to have some way to let the compiler know to use ... because gfortran assumes the C convention, ...
    (comp.lang.fortran)