Re: need to define _ISOC99_SOURCE

[Paul Eggert <eggert at twinsun dot com>]

   From: Akim Demaille <akim@epita.fr>
   Date: 27 Jul 2000 11:31:41 +0200

   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.

It's more reasonable to move them into the C compiler check.  The
problem here is to identify the right C compiler options to use when
plain $CC is pedantic for some reason.  The issue here is broader than
just AC_CHECK_FUNC; feature-test macros can also make macros or enums
visible, for example.

   For instance, why wouldn't we always define _GNU_SOURCE?  And why
   does it exist?

One should have to define _GNU_SOURCE only if the compiler is picky
(e.g. gcc -ansi).  In that case, you must define _GNU_SOURCE to make
the extra identifiers visible, as their presence is incompatible with
the standard.

However, GNU applications tend to avoid pickiness options like -ansi;
they just causes too many problems.  So there shouldn't be any reason
for them to define _GNU_SOURCE in theory.  Apparently, though, in
practice there are sometimes incomptabilities between gcc and glibc
(e.g. the current versioning problem relating to the upgrade to C99),
which cause the library to mistakenly think the compiler is being
operated pedantically.  It makes sense to define _GNU_SOURCE to work
around these glitches.

The simplest workaround for this problem is for autoconf to do the
equivalent of the following before compiling any C programs:

AC_DEFINE(_GNU_SOURCE, 1,
  [Define unconditionally for setting a GNU environment.])

GNU tar's configure.in has been doing this since April 1997 (tar
version 1.12) with nobody reporting any problems.

Perhaps AC_AIX could be done automatically as well.  I don't offhand
see any reason to omit it.  Similarly for _HPUX_SOURCE -- but doesn't
the latest autoconf already do HPUX_SOURCE automatically?  At any
rate, I think the above macros should be defined by default as needed,
though perhaps there should be a way for configure.in to disable this
(for weird maintainers who actually prefer their ports to use picky
and limited compilation environments :-).

    - Macro: AC_PROG_GCC_TRADITIONAL

   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?

I would deprecate it.  First, it's way obsolete -- the systems it
addresses were obsolescent even in 1992 and have died off since then.
Second, it didn't really solve the problem in general.  In practice,
obsolete headers cause problems that adding -traditional doesn't fix.
Perhaps the currently most-common problem with obsolete headers is
people using GCC 2.7.2.x on Solaris 2.6 or later -- and these headers
are all ANSI C.