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: Rich Felker <dalias at aerifal dot cx>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Christoph Hellwig <hch at lst dot de>, libc-alpha at sourceware dot org
- Date: Sat, 15 Mar 2014 22:36:54 -0400
- Subject: Re: Problems with evolving feature test macros?
- Authentication-results: sourceware.org; auth=none
- References: <CAKgNAki3SzAN8rZjvMQxbqDkpRGBzsmNGBKMJ0DDcMAG0nG8gQ at mail dot gmail dot com> <531F3E8F dot 4070204 at cs dot ucla dot edu> <CAKgNAkiTBRwUuquUrf8pMSmbKGn11UxY=b85pzSq+PKKk9sq+w at mail dot gmail dot com> <9377251 dot S2YQ79AfuF at vapier> <CAKgNAkj+P69LCSO9xMNBbFW7FOy7v+DL5cAkat6dNRahfjMXOQ at mail dot gmail dot com> <5323159A dot 30208 at cs dot ucla dot edu> <20140315140315 dot GA29851 at lst dot de> <532509AD dot 9070107 at cs dot ucla dot edu>
On Sat, Mar 15, 2014 at 07:17:17PM -0700, Paul Eggert wrote:
> Christoph Hellwig wrote:
> >if I want to write a portable application having libc help me using
> >only APIs provided in a well defined standard is useful
>
> In theory that argument makes sense, but in practice almost nobody
> writes strictly conforming applications because it's too much
> trouble and these applications would have to do without too many
> useful features and speedups. Instead, portable applications tend
> to take an Autoconf-style approach, and accommodate themselves to
> whatever the platform has to offer.
The fact that this is widespread in practice doesn't mean it's
necessary or beneficial. In fact most bad coding practices seem to
spread mostly from people seeing bad examples and copying them
(often a matter of cargo-culting).
What portion of applications really benefit from using nonstandard
features is a good open question. This, combined with a study of which
nonstandard features are widely important (I'd wager MAP_ANONYMOUS is
one of the most widely needed) would in turn be very helpful to the
standards bodies for improving the standards.
>From an application or library standpoint, it's a lot EASIER to just
write your code to the standards and not have to worry about multiple
code paths selected by #ifdefs. It's easier to setup and maintain the
build system and easier to test the code (since you don't need to test
all combinations of HAVE_*'s). If there's extended functionality you
really really want/need to support when it's available, then yes you
have to take the more difficult option of detection (e.g. autoconf) or
manual configuration (aka hell) but I'd much rather be in the position
of not having to do either.
> For more about why strictly-conforming apps are rare, please see:
>
> Walli SR. The myth of application source-code conformance.
> StandardView 1996;4(2);94â9. http://dx.doi.org/10.1145/234999.235002
Paywalled...
Rich