This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


I think appropriate conservatism is to start with a change that just
eliminates __FAVOR_BSD.  We might even want to go through a release
cycle like that (but maybe not).

In the past, I'm pretty sure I've seen (non-GNU) packages that use
-D_BSD_SOURCE -D_SVID_SOURCE to get "common" extensions without getting
GNU extensions (some of which have names that might be more likely to
have been used by applications--getline was a common case, at least
before it was added to POSIX).  So perhaps there is a need for something
like that.  I guess we could start (after removing __FAVOR_BSD stuff)
with an analysis of what names are enabled by _GNU_SOURCE but not the

I'm not really sure exactly how to proceed.  But I think it needs to be
more conservative and incremental than this change looks to me off hand.

I think the suggestion of a feature-test macro that enables all the
extension symbols but does not change any standard-specified symbols has
merit.  It is probably wise to add this first, and then stage the
removal of the old feature-test macros.  A long-term intermediate state
that probably makes sense is to have _BSD_SOURCE and _SVID_SOURCE
(without _GNU_SOURCE) trigger this new mode but with a #warning advising
to use the cleaner new feature-test macro name.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]