Mixing function pointers and regular functions with the _EXFUN macro

[Jerker Bäck <jerker dot back at gmail dot com>]

Hello,

This is a repost of a bug report originally posted at sourceware bugzilla
and previously posted here as "newlib bug report".

http://sourceware.org/bugzilla/show_bug.cgi?id=11073
http://sourceware.org/bugzilla/attachment.cgi?id=4454&action=view
http://sourceware.org/ml/newlib/2009/msg01085.html

sorry for the mess.

I attached a testcase with test results at the same place (just to be
consistent).

Test case source:
http://sourceware.org/bugzilla/attachment.cgi?id=4462&action=view

Test result:
http://sourceware.org/bugzilla/attachment.cgi?id=4463&action=view

Test result GCC assembler listing
http://sourceware.org/bugzilla/attachment.cgi?id=4464&action=view


I'm assuming that the _EXPARM macro (_ansi.h) is intended to be used for
function pointers. In current newlib both function pointers and regular
functions are declared with the _EXFUN macro. That is OK (although not very
articulate), unless the __CYGWIN__ macro is defined and activates the
__cdecl function modifier keyword.

The proposed patch change function pointer declaration to use the _EXPARM
macro instead of the _EXFUN macro. It also change the order (syntax) of the
__cdecl keyword in the _EXPARM macro.

The test case examines consequences of different calling convention
declaration syntax for different compilers. The MS and Intel compilers gives
an error with current newlib _EXPARM define. GCC seems indifferent of which
syntax used (implemented as an attribute). This I'm bold enough to suggest
is a lack of a syntax check, not as a deliberate implementation (i.e. this
is a GCC bug).

The __cdecl, __stdcall and __fastcall are classic keywords for Windows
compilers going back to the DOS age, describing the calling convention used
by the function. __stdcall and __fastcall are considered faster than __cdecl
and __stdcall is heavily used in the Win32 API while __fastcall is popular
in Borland APIs. I'm not going to argue about semantics as there are plenty
sources of information on the net about this. A correct implementation could
probably be studied in the Open Watcom compiler source
(http://www.openwatcom.org). At least we can conclude there is a well
established standard how these keywords should be applied. I cannot see any
reason why newlib should have its own semantics, especially when it breaks
at least 2 compilers.

==============================================

Dave K >   (Also, what's "cc-script"?

The "cc-script" is a shell script originally from OpenNT/Interix and enables
using a Windows compiler with BSD/GNU Makefiles i.e. providing a kind of
unix cc frontend. My script is a from scratch rewritten version and is using
a wide range of tools and compilers e.g. yasm and the compilers mentioned.
So yes, one objective is to be able to run this script /on/ Cygwin as well
as /for/ Cygwin.


Cheers
Jerker B