Re: need to define _ISOC99_SOURCE

[Akim Demaille <akim at epita dot fr>]

|    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.

OK, I prepare a patch along these lines.


| 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.

OK, thanks!

| 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.])

C and C++ or just C?


| 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?  

Only with AC_PROG_CC_STDC.

| 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 :-).

Well, we'll keep them in separate macros which people might define to
empty if they wish, but I'd rather not document such thing: it's just
a provision in the case something goes wrong, but I don't think we'll
need that.


|     - 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.

Thanks Paul!  What I particularly enjoy with your answers is that I
just have to cut and paste, and voilą! a nice addition to the
documentation :)

        Akim