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
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
