This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: need to define _ISOC99_SOURCE


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]