| msg6930 - (view) |
Author: Frederic Giacometti (giacometti) |
Date: 2001-10-15 19:18 |
| 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 |
|
|
| msg6931 - (view) |
Author: Tim Peters (tim.peters) *  |
Date: 2001-10-15 19:34 |
| 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. |
|
|
| msg6932 - (view) |
Author: Frederic Giacometti (giacometti) |
Date: 2001-10-15 19:46 |
| 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 |
|
|
| msg6933 - (view) |
Author: Mark Hammond (mhammond) * |
Date: 2001-10-16 01:45 |
| 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. |
|
|
| msg6934 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2001-10-16 03:00 |
| 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>. |
|
|
| msg6935 - (view) |
Author: Frederic Giacometti (giacometti) |
Date: 2001-10-16 17:19 |
| 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 |
|
|
| msg6936 - (view) |
Author: Brett Cannon (brett.cannon) * |
Date: 2007-03-20 22:05 |
| This is a rather old bug. =) If no one cares to fix this then it should be closed. |
|
|
| msg6937 - (view) |
Author: Brett Cannon (brett.cannon) * |
Date: 2007-03-28 02:36 |
| No one has cared for a week, so closing as out of date. |
|
|