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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
