On Tue, 18 Oct 2016, Carlos O'Donell wrote:

> On 10/18/2016 11:57 AM, Joseph Myers wrote:
> > On Tue, 18 Oct 2016, Florian Weimer wrote:
> > 
> >> However, TS 18661-1 added “iszero” to <math.h>, and this causes some build
> >> failures.  Apparently, the main problem here is that it is a macro, which
> >> means it is not subject to scoping (which helps C++ in particular to cope with
> >> definitions of nextup/nextdown/fsub/canonincalize).
> > 
> > I think some build failures are inevitable with new features in headers; 
> > applications that use _GNU_SOURCE simply need to be updated, just as 
> > applications that defined their own getline function but didn't define 
> > _GNU_SOURCE needed updating when getline was added to POSIX and so to the 
> > default glibc API, and just as applications routinely need updating when 
> > new GCC versions add new diagnostics or increase the default C and C++ 
> > standards used.
> 
> Is _GNU_SOURCE too big of a feature macro to be useful anymore?

It's useful (as is AC_USE_SYSTEM_EXTENSIONS), but it's in its nature that 
the set of APIs it enables expands over time and so application and 
distribution maintainers have to be prepared to update software using it 
when new APIs conflict with names used by that software.  Without having 
seem distribution rebuild results for API additions in glibc, I'd guess 
they generally cause far fewer problems per release cycle than e.g. the 
GCC moves to gnu11 / gnu++14 as default C and C++ standards did.

-- 
Joseph S. Myers
joseph@codesourcery.com