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