This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Problems with evolving feature test macros?
- From: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, Andreas Jaeger <aj at novell dot com>
- Date: Tue, 11 Mar 2014 20:25:22 +0100
- Subject: Re: Problems with evolving feature test macros?
- Authentication-results: sourceware.org; auth=none
- References: <CAKgNAki3SzAN8rZjvMQxbqDkpRGBzsmNGBKMJ0DDcMAG0nG8gQ at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1403111804230 dot 480 at digraph dot polyomino dot org dot uk>
- Reply-to: mtk dot manpages at gmail dot com
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
?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/