Re: need to define _ISOC99_SOURCE

[Paul Eggert <eggert at twinsun dot com>]

   From: Akim Demaille <akim@epita.fr>
   Date: 31 Jul 2000 12:14:49 +0200

   my proposal always defines _GNU_SOURCE and _ALL_SOURCE

I suggest always define __EXTENSIONS__ too.  Solaris uses that symbol
to define all extensions that are not incompatible with whatever
standard is in use.  __EXTENSIONS__ normally doesn't come into play,
but occasionally people mistakenly compile with gcc -ansi or something
like that, and it'd be nice to be immune to these glitches.

I would also define _XOPEN_SOURCE to 500 if that helps.  The symbol to
try there is ftello: if <stdio.h> declares ftello when _XOPEN_SOURCE
is defined to 500, but does not declare ftello otherwise, then you
should define _XOPEN_SOURCE.  This is needed for glibc 2.1.3; see the
source code to AC_SYS_LARGEFILE, which I guess could be simplified a
bit if the _XOPEN_SOURCE definition is done elsewhere.

I would mark AC_MINIX and AC_ISC_POSIX as obsolescent, as I think that
the problems that those macros address are long dead.  Similarly, I
wouldn't bother with _POSIX_1_SOURCE.

   Also, I used a protected form for both (with ifndef guards).

I don't think that's needed, as config.h comes first.  I don't think
we need to worry about people putting -D_GNU_SOURCE=2 and the like in
their CFLAGS.  After all, we don't worry about -DHAVE_VFORK=2, and it
is analogous.

   I am also tempted to define unconditionally these symbols:

   #define _POSIX_SOURCE 1
   #define _POSIX_1_SOURCE 2

I would define these symbols only if they make POSIX symbols visible
that are otherwise invisible.  This can be done automatically.

Probably the right order to do these tests is _GNU_SOURCE first; then
_ALL_SOURCE, __EXTENSIONS__, _HPUX_SOURCE (in any order); then
_XOPEN_SOURCE; then the following algorithm for defining _POSIX_SOURCE
and friends.

* Try compiling and linking a test program that uses POSIX features
  that some misguided implementations turn off by default.  (You have
  to link and not just compile, as I recall the problem on some hosts
  partly depends on renaming symbols and archive naming.)

* If that works, leave _POSIX_SOURCE and POSIX_C_SOURCE alone.
  Otherwise, try compiling and linking with the following options, one
  by one:

  -D_POSIX_C_SOURCE=2147483647
  -D_POSIX_SOURCE=

  and use the first definition (if any) that fixes the problem.

  The 2147483647 means `give me the latest version that you've got'.

Here is a suggested test program, derived from the RCS test program.
It tests for fileno, as that is the canonical symbol that causes
problems with POSIX implementations.  (The C standard says that
stdio.h must not define fileno.)  You can add more tests if you like.

#include <stdio.h>

int
main ()
{
  /* Check that fileno is properly declared.  This fileno test must
     come first, as the other tests declare fileno as a side effect
     if the compiler is pre-C99.  */
  int i1 = !fileno;

  /* Check that ordinary fileno works.  */
  int i2 = fileno (stdin);

  /* Check again with the fileno function, to make sure it gets linked in.  */
#undef fileno
  int i3 = fileno (stdin);

  /* Make sure all the test values get used, so that references to
     functions don't get optimized away.  */
  return i1+i2+i3;
}