On 12/07/11 09:01, Francois Gouget wrote:
#ifdef __i386__
#define DEFINE_WRAPPER_FUNC(n, off, x) \ HRESULT wrapper_func_##n(IUnknown*); \
[...]
#elif defined(__x86_64__)
#define DEFINE_WRAPPER_FUNC(n, x, off) \ HRESULT WINAPI wrapper_func_##n(IUnknown*); \
[...]
#else
#define DEFINE_WRAPPER_FUNC(n, x, off) \ static HRESULT WINAPI wrapper_func_##n(IUnknown *iface) { \
[...]
Is it normal that these functions are still marked as WINAPI in the 64bit and other platform cases?
Well, it doesn't really matter since these functions are implemented in assembly and they are actually a trick for calling functions we don't know anything about (current implementation will work correctly for any cdecl and stdcall functions on 32-bit and any standard MS ABI function on 64-bit), so we can't have the right declaration anyways. On 32-bits, declaring them as stdcall causes GCC to mangle names with argument count when referenced in vtbls, which caused linker warnings (in old GCCs it would probably be even errors). I kept WINAPI for 64-bit variant just to declare MS ABI, but, since the declaration doesn't really matter, it's just a cosmetic thing. For other platforms it matters even less - if we reach these calls, we should expect problems anyway.
Also, is there a reason not to mark these functions as static in the Intel cases? Because they are coded in assembly?
Well, talking about C declaration, it causes warnings like these here:
ifacewrap.c:215:1: warning: 'wrapper_func_99' used but never defined
That's because GCC has no way to know that it's defined in assembly. Then, again, marking them as static in C declarations won't make them true statics functions anyway.
Jacek