Re: Test for GNU/XSI version of strerror_r

[Florian Weimer <fw at deneb dot enyo dot de>]

* 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++.