need to define _ISOC99_SOURCE
James Antill
james@and.org
Thu Jul 27 08:29:00 GMT 2000
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.
For autoconf-2.23 you only have AC_CHECK_FUNC() for stpcpy (the
development version may have done a AC_FUNC_STPCPY I'm don't know) and
AC_CHECK_FUNC() _doesn't_ honor _GNU_SOURCE etc. (it just checks for
the symbol in the library).
So the only feasable course of action is that you _must_ #define
_GNU_SOURCE if you use autoconf. At which point this entire argument
becomes mute (I'm assuming that _GNU_SOURCE defines the ISOC99
namespace) because no matter what glibc or gcc do by default (and I'd
argue that they are doing fine) a gnu program will always have access
to all of the namespace.
--
James Antill -- james@and.org
"If we can't keep this sort of thing out of the kernel, we might as well
pack it up and go run Solaris." -- Larry McVoy.
More information about the Libc-alpha
mailing list