Hello Alsessandro
As you already pointed out: "The time and speed...
I'm not going to argue about Microsoft visavi something else - in fact I'm
dead tired about this never ending antagonism. The supposed target will
never get hit, it just narrows the interested community.
Neither do I think that this is a place for a discussion of the meaning,
advantage or disadvantage of __cdecl, __stdcall, __fastcall. Besides, I have
too little assembler skill to take part of such a discussion.
It is simply a fact that these keywords are used in Microsoft, Intel and
Borland compilers. Users may have to deal with them when compile GNU make.
Adding support for these are a minor effort and will not affect other
compilers.
To support calling conventions:
#if !defined(__cdecl) && !defined(_MSC_VER) && !defined(__BORLANDC__)
#define C_CALLBACK
#else
#define C_CALLBACK __cdecl
#endif
extern int C_CALLBACK alpha_compare PARAMS((const void *, const void *));
int C_CALLBACK alpha_compare (const void *v1, const void *v2)
{ ...
Note: Only local functions called by external library functions should be
defined.
> `callback'?! I guess you mean `call'. There is no need to
> specify a calling convention to invke a C function.
Yes I meant "callback" functions, the ones you supply as a function pointer
and are supposed to do some work and finally give you a reply. The only
affected function in GNU make are qsort calls. The supplied local function
pointer must have __cdecl calling convention. I'm not really sure but I
think all this works for Borland compilers too.
Kind regards Jerker
_______________________________________________
Make-w32 mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/make-w32
