make-w32
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: MS compiler 7.1 (Visual Studio .NET 7.1 and DDK 2003) issues withmak


From: Jerker Bäck
Subject: RE: MS compiler 7.1 (Visual Studio .NET 7.1 and DDK 2003) issues withmake 3.80
Date: Mon, 25 Apr 2005 13:59:18 +0200

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]