Mixing function pointers and regular functions with the _EXFUN macro

[Jeff Johnston]

Jerker,

Leave the original _EXPARM macro alone and create a new macro: _EXFNPTR 
which you can define as you have changed _EXPARM.  Use the new macro in 
your patch and please post the finished patch "here" and not in the bug. 
  I am going to close bugzillas from now on immediately.

If you can do this by tomorrow afternoon, I'll get the patch in for the 
snapshot.

-- Jeff J.

On 14/12/09 06:53 PM, Howland Craig D (Craig) wrote:
> 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
>
>