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: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 11 Mar 2014 18:58:30 +0100
- Subject: Re: Problems with evolving feature test macros?
- Authentication-results: sourceware.org; auth=none
- References: <CAKgNAki3SzAN8rZjvMQxbqDkpRGBzsmNGBKMJ0DDcMAG0nG8gQ at mail dot gmail dot com> <531F34C8 dot 9000500 at cs dot ucla dot edu> <CAKgNAkj5Bn8oSEPcpoiw6HnoE6hoNkHP6VAZBt2h5z4UPDAeDA at mail dot gmail dot com> <531F3E8F dot 4070204 at cs dot ucla dot edu>
- Reply-to: mtk dot manpages at gmail dot com
On Tue, Mar 11, 2014 at 5:49 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 03/11/2014 09:33 AM, Michael Kerrisk (man-pages) wrote:
>>
>> That weakens the whole idea of having a
>> range FTMs (as opposed to just _GNU_SOURCE, say), it seems to me.
>
> Exactly. Those fancy feature-test macros are typically more trouble than
> they're worth. They're mainly of interest to standards nerds, not
> developers.
So, you'd say always just define _GNU_SOURCE and be done with it?
>> I have no specific examples to cite.
>
> Likewise for most developers of portable software, which is why this is a
> non-issue for them. Feature-test macros don't suffice for portable
> software, and typically aren't even helpful; they mostly just get in the
> way..
Well, given that perspective, why go through the current effort trying
to tidy things up/
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/