Problems with evolving feature test macros?

[Rich Felker]

On Tue, Mar 11, 2014 at 01:52:02PM -0700, Paul Eggert wrote:
> On 03/11/2014 12:13 PM, Rich Felker wrote:
> >>It's typically only a minor annoyance.
> >No, it's very unfortunate because defining _GNU_SOURCE breaks
> >strerror_r, basename,
> Even those glitches, which are indeed unfortunate, are minor
> annoyances.  You can easily fix the former with Autoconf's
> AC_FUNC_STERROR_R macro, for example, and that's what GNU
> applications commonly do.And basename is so broken that portable
> applications should avoid it and write their own.
> 
> The real problems in portability are elsewhere.  These problems are minor.

I agree basename is a junk interface that should never be used, but
strerror_r is a real problem. The only alternatives are:

strerror - not thread-safe, though it should be,

snprintf with %m - clean api but not testable at compiletime so not
feasible to use anywhere

strerror_l - not widely available, and needs a locale_t arg

strerror_s - also not widely available

Adding autoconf infrastructure into translation units/libraries meant
to be portable (so they can be aware of and use the broken gnu
strerror_r) is not a reasonable solution.

glibc really needs a way to add onto _GNU_SOURCE a "don't break
standard functions" request. A clean way to do this would be to make
it so _POSIX_C_SOURCE or _XOPEN_SOURCE, when explicitly requested, add
a __PREFER_STANDARDS feature that overrides the breakage even if
__USE_GNU is active.

Rich