Test for GNU/XSI version of strerror_r

Test for GNU/XSI version of strerror_r

[Ian Pilcher]

I am writing a Python extension that calls strerror_r.  Unfortunately,
the Python extension build system requires that Python.h be the first
header file included; it also sets the _GNU_SOURCE feature test macro
*and* includes string.h.

If I define _GNU_SOURCE before including Python.h, I receive a warning
about the macro being redefined.  AFAICT, gcc does not provide a way to
suppress this warning.

My tests show that I am getting the GNU version of strerror_r, but I
hate relying on the internal structure of the Python header files (even
more that I hate warnings).

So I'm trying to come up with a compile-time check, to ensure that
strerror_r has the desired signature (i.e. it returns a char *, not an
int).  Here's what I've got:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-variable"
#pragma GCC diagnostic error "-Wincompatible-pointer-types"
__attribute__((unused))
static inline void check_for_gnu_strerror_r(void)
{
     /*
     * If this causes an 'incompatible pointer type' error, strerror_r is
     * the XSI-compliant version; we need the GNU-specific version.  See
     * strerror(3).
     */
     char *(*foo)(int, char *, size_t) = strerror_r;
}
#pragma GCC diagnostic pop

This appears to work, but it (obviously) generates a completely
unhelpful error message.  It also has the potential to actually output
the code for check_for_gnu_strerror_r(), although a simple test at -O3
shows it being optimized completely out.

Is there a better way to do this?

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================

Re: Test for GNU/XSI version of strerror_r

[Florian Weimer]

* Ian Pilcher:

> Is there a better way to do this?

Can you use C++?

Re: Test for GNU/XSI version of strerror_r

[Ian Pilcher]

On 10/4/19 2:16 PM, Florian Weimer wrote:
> * Ian Pilcher:
> 
>> Is there a better way to do this?
> 
> Can you use C++?
> 

Well, I did say better.  ;-)

The extension is quite a simple.  (It provides a single function, which
changes to a non-root user while retaining CAP_NET_ADMIN.)  It will
likely weigh in under 100 lines.  Also, I haven't touched C++ since the
1990s.  (I still have the Turbo C++ 3.0 box!)

Given all that, I don't think it's worth introducing the extra
complexity of adding an additional source file or compiling the
extension with g++.  (I did stumble across a few C++-based solutions to
this problem before posting.)

Thanks!

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================

Re: Test for GNU/XSI version of strerror_r

[Florian Weimer]

* Ian Pilcher:

> On 10/4/19 2:16 PM, Florian Weimer wrote:
>> * Ian Pilcher:
>> 
>>> Is there a better way to do this?
>> 
>> Can you use C++?
>> 
>
> Well, I did say better.  ;-)
>
> The extension is quite a simple.  (It provides a single function, which
> changes to a non-root user while retaining CAP_NET_ADMIN.)  It will
> likely weigh in under 100 lines.  Also, I haven't touched C++ since the
> 1990s.  (I still have the Turbo C++ 3.0 box!)

You could use generic selection and _Generic.  But these days, that's
more restrictive than C++ in terms of compiler support.

It's not really defined to add “#define _GNU_SOURCE” after the first
#include, so you could probably just check for _GNU_SOURCE.

Re: Test for GNU/XSI version of strerror_r

[Ian Pilcher]

On 10/4/19 2:37 PM, Florian Weimer wrote:
> You could use generic selection and _Generic.  But these days, that's
> more restrictive than C++ in terms of compiler support.

I only care about gcc, but I do need to support 4.8.5 (in EL7), so it
looks like that isn't an option.

> It's not really defined to add “#define _GNU_SOURCE” after the first
> #include, so you could probably just check for _GNU_SOURCE.

I'm actually doing that as well.  I just wanted to catch the (admittedly
pathological) case where Python.h includes string.h *before* defining
_GNU_SOURCE.

Here's what I've got so far.  (It looks like my 100-line estimate may
have been a bit low.  Gotta love C!)

   https://pastebin.com/WBH1FPwC

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================

Re: Test for GNU/XSI version of strerror_r

[Florian Weimer]

* Ian Pilcher:

> On 10/4/19 2:37 PM, Florian Weimer wrote:
>> You could use generic selection and _Generic.  But these days, that's
>> more restrictive than C++ in terms of compiler support.
>
> I only care about gcc, but I do need to support 4.8.5 (in EL7), so it
> looks like that isn't an option.

That's in part what I meant.  Even C++98 has the necessary tools for
this kind of test, and C11 is not universally available.

>> It's not really defined to add “#define _GNU_SOURCE” after the first
>> #include, so you could probably just check for _GNU_SOURCE.
>
> I'm actually doing that as well.  I just wanted to catch the (admittedly
> pathological) case where Python.h includes string.h *before* defining
> _GNU_SOURCE.
>
> Here's what I've got so far.  (It looks like my 100-line estimate may
> have been a bit low.  Gotta love C!)
>
>    https://pastebin.com/WBH1FPwC

You could try to come up with something using
__builtin_types_compatible_p:

<https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005ftypes_005fcompatible_005fp>

For the nice error message, you could try the error function attribute
in a conditional expression using __builtin_types_compatible_p:

<https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-error-function-attribute>

The glibc headers have some examples for that (search for __errordecl).

All this is much more well-defined with _Generic or in C++.