This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Mixing function pointers and regular functions with the _EXFUN macro


A thought related not to the goal of this patch, but to a detail of how
it is done.
 
The stated intent of the _EXFUN macro is to be used for defining function
parameters.  (2000-09-06 ChangeLog entry says "New macro for defining a
function parameter.")  The proposal assumes a more general intent, and
the patch accordingly uses it for purposes other than this.  For example
(the diff coming in the middle of the struct __sFILE definition in
libc/sys/reent.h):

-  _READ_WRITE_RETURN_TYPE _EXFUN((*_read),(struct _reent *, _PTR,
+  _READ_WRITE_RETURN_TYPE _EXPARM((_read),(struct _reent *, _PTR,
 
I have thought of two objections to using _EXPARM outside of function
parameter lists--both of which relate to maintenance, not to proper function.
 
First, the name _EXPARM does not make sense in this context--in a
structure, for example, what sense does it make to have an "external
parameter" member?  (A result of extending the use beyond its original
intent, which speaks only to lack of perfect foresight in the original
wording, and not to the goal of this patch.)

Secondly, using it in this context removes the * from in front of the
function pointer name, which makes it much less obvious that a function
pointer is the item in question--a bit of a step backwards.  That is,
with the * there (e.g. *_read of the present form), it only takes a glance
to see it is a pointer.  Without the *, it takes a partially-informed
guess--or a-priori knowledge--that a function pointer is the subject.
 
Both of these objections could be eliminated by changing the name of
the macro.  Given that a major reason for using the macro at all is that
the _cdecl stuff needs to be brought in, a name keeping EX at the front
is probably best.  So instead of _EXPARM(), something like
_EXFUNCPTR(), _EXFUNCP(), _EXFP(),
_EXFPTR(), _EXFNPTR(), _EXFTNPTR(), etc.
(I don't think that any of these are ideal, but they are much more clear
than _EXPARM.)
 
For the sake of a starting point for discussion, I suggest that _EXPARM
should be changed to _EXFUNCPTR.  (This could be considered independently
of this patch, of course, but it probably makes sense to tie them
together.)  The intended use of the macro would be for function pointers
used in parameter lists and in structure declarations--the two cases
for which it is being used in the proposed patch.
 
Craig

-----Original Message-----
From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org] On Behalf Of Jerker Bäck
Sent: Friday, December 11, 2009 8:08 AM
To: newlib@sourceware.org
Cc: 'Dave Korn'; jjohnstn@redhat.com
Subject: Mixing function pointers and regular functions with the _EXFUN macro

...

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.

...
Cheers
Jerker B



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]