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.
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.
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"?
--
Fredrik Tolf
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
