Symbol management in header files

Symbol management in header files

[Florian Weimer]

Historically, -D_GNU_SOURCE turns out all optional features in header 
files.  All in all, this is a good thing because it makes simple for 
programmers, and something like this is needed for using glibc features 
in header-only libraries.  No one wants repeats of strerror_r, basename, 
or snprintf.

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).

Is there anything we can do about this?  Do we need some guidance for 
dealing with standards which define macros with generic names?

(Let's keep the discussion here focused on source-code compatibility; I 
will start another thread about symbol management at the ELF level.)

Thanks,
Florian

Re: Symbol management in header files

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Symbol management in header files

[Carlos O'Donell]

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?

-- 
Cheers,
Carlos.

Re: Symbol management in header files

[Paul Eggert]

On 10/18/2016 09:00 AM, Carlos O'Donell wrote:
> Is _GNU_SOURCE too big of a feature macro to be useful anymore?

No, it's what is wanted in many GNU applications (e.g., GNU Emacs, 
coreutils). Their 'configure' scripts rely on _GNU_SOURCE, and when new 
features like iszero are added to the GNU system, these applications are 
updated accordingly. For these applications, I daresay that 
smaller-scope macros would be less appealing than the current situation; 
they'd continue to use _GNU_SOURCE.

Re: Symbol management in header files

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

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

Re: Symbol management in header files

[Florian Weimer]

On 10/18/2016 05:57 PM, 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,

_GNU_SOURCE currently is pretty much mandatory for C++, so this isn't 
really a case of deliberate opt-in.  All the build failures I have seen 
so far were encountered by C++ code.

It seem we need to be more careful with adding non-namespaced macros to 
central header files under _GNU_SOURCE, at least for C++.

Thanks,
Florian