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

[noreply@sourceforge.net]

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: 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