Bugs item #471432, was opened at 2001-10-15 12:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=471432&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific >Status: Closed >Resolution: Out of Date Priority: 5 Private: No 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: Brett Cannon (bcannon) Date: 2007-03-27 19:36 Message: Logged In: YES user_id=357491 Originator: NO No one has cared for a week, so closing as out of date. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-20 15:05 Message: Logged In: YES user_id=357491 Originator: NO This is a rather old bug. =) If no one cares to fix this then it should be closed. ---------------------------------------------------------------------- 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: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=471432&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com