Re: Use system extensions conditionally?

[Eric Blake]

On 02/26/2014 11:12 PM, Fredrik Tolf wrote:

> 
>> Yes, it really is bad practice to mix compilation tests before turning
>> extensions with compilation tests done afterwards.  Turning on
>> extensions is such a drastic change to the compilation environment that
>> you want ALL your tests to run under the same environment.  Either you
>> plan on using extensions, and should enable them unconditionally up
>> front, or you do not need extensions, and should not use the macro.
> 
> Hm. I see your reasoning, and I see where you're coming from. However,
> on FreeBSD, I don't actually have to turn on any extensions to use the
> corresponding functionality (funopen &c.). Isn't it ugly, then, to
> always enable system extensions, regardless of environment?

No.  Most programs WANT to blindly turn on all extensions, regardless of
environment, because it is easier to write programs that can take
advantage of extensions, regardless of how cavalier the system is about
namespace pollution even when extensions are not requested.  I could
argue that FreeBSD has a bug in that it is not strictly POSIX compliant
if funopen() is exposed by default when requesting POSIX compliant, but
when extensions are requested, the namespace pollution of exposing
funopen() is reasonable (but I'd actually have to test compilation on
FreeBSD when my C source pre-defines _POSIX_C_SOURCE prior to including
system headers, to determine whether funopen() is actually leaked when
requesting strict compliance).

There is a small set of projects that really DOES want to remain
completely POSIX-compliant (or even stricter ANSI-C compliant) - those
programs do NOT want to request extensions by default, so that they
minimize namespace pollution from system headers.  But they tend to be
the minority.

In my own experience, projects that use gnulib almost always end up
using AC_USE_SYSTEM_EXTENSIONS under the hood, because gnulib is best
able to implement lots of functionality when it can rely on system
extensions.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature