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: Open
Resolution: None
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-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
