Re: Use system extensions conditionally?

[Eric Blake]

On 03/01/2014 08:32 PM, Fredrik Tolf wrote:
> On Thu, 27 Feb 2014, Eric Blake wrote:
>>> 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.
>> [...]
>> 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.
> 
> Thanks for your reply!
> 
> I've been mulling over it for a while now, but I still don't think I
> quite get it. In particular, I'm still not in the clear about what
> AC_USE_SYSTEM_EXTENSIONS really does.
> 
> I read what you write kind of as if systems shouldn't expose anything
> non-POSIX as long as it isn't used, but this is clearly not the case;
> not only with funopen() on *BSD, but also with e.g. epoll() on
> GNU/Linux, or just such things as GCC C extensions.

How do you get epoll() on GNU/Linux?  By including <sys/epoll.h>, but
that's a header that is not mentioned in POSIX.  Therefore, a strictly
conforming program CANNOT use this interface, and therefore there is no
reason to gate that header by _GNU_SOURCE, therefore, there is no need
to use AC_USE_SYSTEM_EXTENSIONS to make use of the interface.

On the other hand, BSD's funopen() is exposed in <stdio.h>, which IS a
standard header; but the name funopen() is not in the list of reserved
name patterns in POSIX.  Therefore, if BSD wants to comply with POSIX,
then when _POSIX_C_SOURCE is defined before including <stdio.h>, then
funopen() must NOT be visible to a user of <stdio.h>.  Now, not everyone
cares about being strictly POSIX-compliant, so the default behavior,
when you don't request extensions, might have names leaked into the
environment.  But on the converse side, when you KNOW you want to use
extensions, you are best off to explicitly request those extensions.
And if you are going to use non-POSIX extensions, you might as well use
all extensions on all platforms, all in one go.

> 
> As such, it seems to me that there are basically three different modes
> of operation: Standards-compliant mode, enabled explicitly by setting
> POSIXLY_CORRECT or similar; extensions mode, enabled explicitly by using
> AC_USE_SYSTEM_EXTENSIONS; and also "default" mode, which is what we have
> if we don't do any of those.

Yes, a fairly reasonable summary (setting POSIXLY_CORRECT alone is not
enough to guarantee a strictly conforming environment, but might be part
of the steps on some platforms, confstr() can be used to determine
whether POSIXLY_CORRECT is required.  Another required step in a
strictly conforming setup is to pre-define _POSIX_C_SOURCE to the
correct value prior to including any system headers).

> 
> Seeing as how there are a lot of extensions available in default mode, I
> don't really see what the formal distinction between default mode and
> extensions mode. I'm willing to buy that there is no formally defined
> distinction between the two, and that the, perhaps arguably sloppy,
> nature of systems development leaves things a bit unclear. But if that
> is so, isn't it still ugly to have to use AC_USE_SYSTEM_EXTENSIONS
> always, on all systems, rather than being left the option of using
> whatever the system considers to be its "default environment"?

glibc is one of the best systems out there that is actively trying to
minimize namespace pollution in default mode.  BSD is slowly catching
up, but not there yet.  Relying on the "default environment" is risky -
something that might be polluted into the namespace today could
disappear tomorrow if the system headers get patched to provide less
pollution.  Explicitly requesting extensions is the only way to ensure
that your program that takes advantage of the extensions will not be
broken by changes to the default mode.


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

signature.asc
Description: OpenPGP digital signature