Re: Problems with evolving feature test macros?

[Rich Felker <dalias at aerifal dot cx>]

On Tue, Mar 11, 2014 at 08:25:22PM +0100, Michael Kerrisk (man-pages) wrote:
> On Tue, Mar 11, 2014 at 7:08 PM, Joseph S. Myers
> <joseph@codesourcery.com> wrote:
> > On Tue, 11 Mar 2014, Michael Kerrisk (man-pages) wrote:
> >
> >> Over glibc versions, it looks as though you can get qecvt() exposed
> >> from <stdlib.h> by defining FTMs as follows
> >>
> >>     Before glibc 2.10:
> >>         _SVID_SOURCE || _XOPEN_SOURCE >= 500 ||
> >>             (_XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED)
> >>
> >>     glibc 2.10 to glibc 2.17
> >>         _SVID_SOURCE || (_XOPEN_SOURCE >= 500 ||
> >>             (_XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED) &&
> >>                 ! (_POSIX_C_SOURCE >= 200809L || _XOPEN_SOURCE >= 700))
> >
> > As a further point: those clearly reflect bugs,
> 
> (Assuming of course that I've derived the right FTM dependencies.)
> But, good to know at least that this all might really be about a bug,
> not an intention.
> 
> > given the absence of qecvt from the relevant standards.
> > In such cases, you can't reasonably expect
> > past buggy states of glibc to be sane, only possibly states that actually
> > reflect the standards containing a given interface.  And someone writing
> > portable software using appropriate _POSIX_C_SOURCE or _XOPEN_SOURCE
> > macros will need to decide to what extent they wish to work around bugs in
> > the set of symbols exposed by those macros in old libraries.
> >
> > If you wish to document bugs, documenting them in the BUGS section of the
> > manpage seems most appropriate.
> 
> Yikes, no! It's hard enough just trying to document the desired
> approach (given that some those changes were made with pretty minimal
> explanation), let alone the bugs.
> 
> Really, what I'd like to see documented is a minimal sane set of FTMs
> that need to be employed, which may also evolve somewhat over time
> (and the evolution would also be documented). Clearly the above is not
> sane.
> 
> Perhaps in this case, the minimal sane set is:
> 
> glibc < 2.20 ==> _SVID_SOURCE
> glibc >= 2.20 ==> _DEFAULT_SOURCE

Random thought: would it hurt to do something like this in feastures.h
and leave it in place for at least the next few release cycles?

#if (defined(_SVID_SOURCE) || defined(_BSD_SOURCE)) && !defined(_DEFAULT_SOURCE)
#define _DEFAULT_SOURCE 1
#endif

This would eliminate the distinction of the legacy FTMs that are being
phased out while making sure they still expose what the user wanted
exposed (and possibly more) (except in the case of "prefer BSD" stuff
being removed entirely, right?).

Rich