need to define _ISOC99_SOURCE
Akim Demaille
akim@epita.fr
Fri Jul 28 03:08:00 GMT 2000
>>>>> "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.
More information about the Libc-alpha
mailing list