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