On 12/18/2016 01:16 AM, Bruno Haible wrote:
> Pedro Alves wrote:
>> m4/inet_pton.m4 has this:
>>
>> if test $ac_cv_have_decl_inet_pton = yes; then
>> dnl It needs to be overridden, because the stdcall calling convention
>> dnl is not compliant with POSIX.
>> REPLACE_INET_PTON=1
>> INET_PTON_LIB="-lws2_32"
>> else
>> HAVE_DECL_INET_PTON=0
>> HAVE_INET_PTON=0
>> fi
>> else
>>
>>
>> Given the "stdcall calling convention is not compliant with POSIX",
>> I wonder whether the right fix would be to somehow cause those
>> functions to be replaced too?
>
> From the point of C programs, replacing 'getaddrinfo' and 'freeaddrinfo'
> is overkill, IMO. Most programs just call these functions the way they are
> declared in the .h file, through direct call, not through function pointers.
>
> I just added some similar replacements for <math.h> functions that are defined
> as inline functions by MSVC. The justification is that <math.h> functions are
> occasionally called through function pointers (e.g. you can imagine a 'plot'
> function, an 'integrate' function, etc. that takes a float->float function
> as a pointer).
>
> From the point of C++ programs:
> - if you get an error in the .h file, from the _GL_CXXALIAS_SYS or
> _GL_CXXALIASWARN invocation for example, or for GNULIB_NAMESPACE,
> it's worth providing the replacement.
> - if you only get an error in a SIGNATURE_CHECK, it's probably not worth it.
> Just conditionalize the the SIGNATURE_CHECK then.
> But if you want to provide the fix through REPLACE_xxx=1, I won't stop
> you.
I agree that full replacement for to handle calling convention
is overkill.
A simpler trampoline stdcall -> cdecl stub/trampoline inline replacement
like the "operator()" one I suggested earlier would be better for these
cases. But even better, I think would be to handle C as well.
I.e., for the case where the system function does not really need
replacement as it works properly, but needs calling convention wrapping,
generate an adapter/trampoline cdecl replacement like:
inline rettype rpl_func parameters
{
return func arguments;
}
and then the C++ wrapper would call rpl_func instead of ::func,
and for C you get the usual '#define func rpl_func'.
But again, this would require tweaking the _GL_CXXALIAS_SYS
macro to pass down the "arguments" list, maybe give it a different
name, _GL_CXXALIAS_SYS_ARGS or some such, and adjusting
all affected _GL_CXXALIAS_SYS calls.
TBC, I'm not planning on proposing a patch.
Thanks,
Pedro Alves
