Re: need to define _ISOC99_SOURCE

[Akim Demaille <akim at epita dot fr>]

>>>>> "James" == James Antill <james@and.org> writes:

James> Akim Demaille <akim@epita.fr> writes:
>> Personally, I hate these macros.  They should just not exist.
>> Either we trace where they are needed and move _ALL_SOURCE into an
>> AC_CHECK_FUNC or so, or we just systematically invoke them, as soon
>> as a C compiler is wanted.
>> 
>> So I'm quite against _HPUX_SOURCE and all those variations, because
>> IMHO the user should just not need to know them.
>> 
>> For instance, why wouldn't we always define _GNU_SOURCES?  And why
>> does it exist?
>> 
>> Alternatively, you say it gives us stpcpy, them _GNU_SOURCES might
>> be defined conditionally by AC_CHECK_FUNC_STPCPY or so.

James>  For autoconf-2.23 you only have AC_CHECK_FUNC() for stpcpy
James> (the development version may have done a AC_FUNC_STPCPY I'm
James> don't know) and AC_CHECK_FUNC() _doesn't_ honor _GNU_SOURCE
James> etc. (it just checks for the symbol in the library).

My point is that we can have such a macro.

James> So the only feasable course of action is that you _must_
James> #define _GNU_SOURCE if you use autoconf. At which point this
James> entire argument becomes mute (I'm assuming that _GNU_SOURCE
James> defines the ISOC99 namespace) because no matter what glibc or
James> gcc do by default (and I'd argue that they are doing fine) a
James> gnu program will always have access to all of the namespace.

Well, the test could avoid defining _GNU_SOURCE when it is not needed,
but I agree it doesn't appear to be needed.