[Python-bugs-list] [ python-Bugs-471432 ] __cdecl (original) (raw)

[Python-bugs-list] [ python-Bugs-471432 ] __cdecl / __stdcall unspecified in *.h

noreply@sourceforge.net noreply@sourceforge.net
Tue, 16 Oct 2001 10:19:56 -0700

Bugs item #471432, was opened at 2001-10-15 12:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471432&group_id=5470

Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Mark Hammond (mhammond) Summary: __cdecl / __stdcall unspecified in *.h

Initial Comment:

Currently, the win32 function call convention (__stdcall vs __cdecl) is never specified in the function prototypes contained in the .h header files.

The call convention is therefore left up to the configuration of the compiler incluing the header files (__cdecl by default on VC++).

However, there are situations in which the compiler default call convention must be set to __stdcall (/Gz option on VC++'s cl.exe), and this makes the link fail; until __cdecl keywords are manually insterted in the Python.h function prototypes required for linking.

[For instance, /Gz is required when using typedef definitions on function pointers, later passed as arguments on __stdcall functions (the default on Microsoft/commercial libraries)].

Besides, Microsoft recommands, it the VC++ documentation, that the __stdcall convention be used by default for function with fixed numbers of arguments (smaller code size and better performances); __cdecl being limited for use with functions with variable number of args ('...').

A solution would consist in defining: #ifdef _MS_VER #define FIXARGCALL __stdcall #define VARARGCALL __cdecl #else ... #endif

and sticking FIXARGCALL / VARARGCALL in front of all DLL_IMPORT(), macro calls associated to a an exported function prototype, across all Python .h files.

Frederic Giacometti

Comment By: Frederic Giacometti (giacometti) Date: 2001-10-16 10:19

Message: Logged In: YES user_id=93657

The fault is not in the other libraries.

In MS Windows, 'well-behaved' libraries define explicitely the calling conventions for each function in their header file. This is all.

There's nobody's guts loosely hanging out in this ;).

FG

Comment By: Tim Peters (tim_one) Date: 2001-10-15 20:00

Message: Logged In: YES user_id=31435

I guess my first question is, if library X needs something other than the default, why isn't it X's responsibility to force their non-default behavior where needed? After all, they're the oddballs. Some days I get real tired of cleaing up after everyone else's loose bowels <0.9 wink>.

Comment By: Mark Hammond (mhammond) Date: 2001-10-15 18:45

Message: Logged In: YES user_id=14198

This does make sense to me, and I have even been bitten by it.

There are some strange libraries out there that need to be compiled with a different calling convention than the default. Trying to extend Python with such a library can be difficult. Having the calling convention specified in the prototypes would solve the problem.

I have never been brave enough to do it, given the small number of times it has been reported as a problem.
However, I would be happy to help come up with a reasonable scheme.

Comment By: Frederic Giacometti (giacometti) Date: 2001-10-15 12:46

Message: Logged In: YES user_id=93657

As far as MS Windows / dll stuff is concerned, you're already swimming in non-C-ANSI fishtank anyway (e.g. DLL_IMPORT() macros...). Just try to keep the right fishes in the tank :))

FG

Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:34

Message: Logged In: YES user_id=31435

Mark, does this make sense to you? Any notion that we have to add non-standard decorations seems inherently fishy to me.

You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471432&group_id=5470