On 2014-03-03 13:50 -0800, Russ Allbery wrote: > Eric Blake <eblake@xxxxxxxxxx> writes: > > > 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. > > Of course, one of the drawbacks is that you have an all-or-nothing > situation. Either you have to stick to only POSIX interfaces, or you have > to give the local system carte blanche to stomp all over your namespace, > possibly resulting in code breakage down the line when some new local > extension is introduced that conflicts with your code. > > This of course isn't a problem that Autoconf can solve. It's basically > inherent in how the feature test macros work. But it's worth being aware > of. All namespace bets are essentially off once you enable system > extensions. Even without the use of system extensions Autoconf makes no attempt to enable standards-conformance mode in compilers, and most of them stomp all over the application namespace by default. So all namespace bets are off with or without AC_ENABLE_SYSTEM_EXTENSIONS. For a concrete example, try to declare a variable called "unix" on a typical GNU/Linux system... Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
