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