Bug 13959

Summary:	Request to deprecate namespace-polluting cruft in headers with _GNU_SOURCE
Product:	glibc	Reporter:	Rich Felker <bugdal>
Component:	libc	Assignee:	Not yet assigned to anyone <unassigned>
Status:	RESOLVED INVALID
Severity:	enhancement	CC:	drepper.fsp
Priority:	P2	Flags:	fweimer: security-
Version:	unspecified
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:

Description Rich Felker 2012-04-07 02:17:11 UTC

When _GNU_SOURCE is defined, a great deal of generally-undesirable cruft is pulled in either directly or as a result of _GNU_SOURCE being built on other __USE_xxx macros. A few examples that come to mind:

- sys/types.h includes sys/sysmacros.h, which defines macros with the ugly names major and minor (lowercase).

- sys/types.h defines BIG_ENDIAN, etc. macros which should be obtained from endian.h if desired.

- sys/param.h defines MIN and MAX macros. (This is less of an issue since it's a non-standardized header anyway, but it's still ugly.)

- math.h defines HUGE as an alias for float.h's FLT_MAX.

- lots more...

Most of this cruft should never be used by modern programs, and mainly exists to begin with as a result of glibc mimicing legacy APIs like SVID. What I'd like to propose is that glibc document clearly which symbols exposed by the headers are actually part of the "_GNU_SOURCE API" versus which are merely cruft, and ideally set a timeline for removing deprecated symbols except when a legacy feature test macro like _SVID_SOURCE is used to request them.

Note that this bug report/enhancement request is really a matter of glibc's documentation and future direction policy rather than a request for any immediate source-level changes.

Comment 1 jsm-csl@polyomino.org.uk 2012-04-07 15:29:21 UTC

On Sat, 7 Apr 2012, bugdal at aerifal dot cx wrote:

> - lots more...

> Note that this bug report/enhancement request is really a matter of glibc's
> documentation and future direction policy rather than a request for any
> immediate source-level changes.

If you want specific changes, "lots more" isn't helpful information about 
those changes.

If you want to discuss policy regarding legacy APIs, libc-alpha would be a 
better place than Bugzilla to discuss the general question of 
reconsidering whether interfaces from BSD and SVID, that are not in POSIX, 
belong in the _GNU_SOURCE API or not.  If there's support for 
reconsidering some such interfaces, then individual bugs could be filed in 
Bugzilla for each case that someone thinks should be removed from the 
_GNU_SOURCE API (the developers may end up disagreeing with some of those 
cases; separate bugs for each case are best to avoid entangling 
consideration of one API with that of other APIs).

Comment 2 jsm-csl@polyomino.org.uk 2012-04-07 15:30:46 UTC

Also: any patch that removes a symbol from the _GNU_SOURCE API certainly 
needs to be tested with building GCC with the patched glibc, given the 
issues we've had with the removal of gets from _GNU_SOURCE and various 
POSIX namespace fixes.

Comment 3 Joseph Myers 2012-06-24 14:47:05 UTC

As discussed on libc-alpha and now documented at <http://sourceware.org/glibc/wiki/Bugzilla%20Procedures>, please take general policy questions and open-ended projects to libc-alpha.  If discussions there conclude that a particular enumerated set of APIs is obsolete for _GNU_SOURCE, a bug could be filed for removing that set, but it would need to list the complete set that had been agreed to be obsolete, with no open-ended "lots more...">