Re: need to define _ISOC99_SOURCE

[Akim Demaille <akim at epita dot fr>]

[I will probably be rejected from cygnus.com, we're black listed, but
they are working on it.  If my message didn't make its way, Bruno,
could you forward it?  TIA].

| Paul Eggert writes:
| > Instead, GNU applications
| > use autoconf to find out what functions are available.  GNU
| > applications don't want to be limited to using only the POSIX
| > functions; they want to run well on their target host, and exploit its
| > extra features.  The GNU C library should support this.
| 
| For GNU applications, this can easily be fixed in the framework of
| autoconf:
| 
| We already have a macro AC_AIX which defines _ALL_SOURCE to get access
| to all reasonable API functions on AIX.
| 
| There ought to exist a macro AC_HPUX which defines _HPUX_SOURCE to get
| access to all API functions on HP-UX.
| 
| There also ought to exist a macro AC_GNU which defines _GNU_SOURCE to
| get access to all reasonable API functions in GNU libc.
|   - mempcpy and stpcpy in <string.h>,
|   - wcwidth in <wchar.h>. (This one could also be done via
|     _XOPEN_SOURCE=500 but Paul Eggert says this should be avoided
|     because it causes havoc on Solaris.)
| 
| Akim, what about two new autoconf macros? <grin>

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.

BTW, there is a macro I dislike even more, it's:

 - Macro: AC_PROG_GCC_TRADITIONAL
     Add `-traditional' to output variable `CC' if using the GNU C
     compiler and `ioctl' does not work properly without
     `-traditional'.  That usually happens when the fixed header files
     have not been installed on an old system.  Since recent versions
     of the GNU C compiler fix the header files automatically when
     installed, this is becoming a less prevalent problem.

I'd like to have opinions on this one: should it be swallowed in an
AC_CHECK_FUNC or so?  Should it be systematically run?  Should we
deprecate this macro?

| Besides that, I agree with Ulrich, that it would cause complications
| to mix a pre-C99 compiler (without features like \uNNNN in strings,
| true/false support in C preprocessor expressions, or _Complex) with a C99
| library. It is really gcc which ought to switch on C99 extensions on
| by default in the next release.

        Akim