> -----Original Message-----
> From: Paul Eggert [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 31, 2000 11:32 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: need to define _ISOC99_SOURCE
>
>
> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 31 Jul 2000 12:14:49 +0200
>
> my proposal always defines _GNU_SOURCE and _ALL_SOURCE
<skipped>
>
> 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.
>
Not exactly: _GNU_SOURCE, _ALL_SOURCE, ... are symbols the normal C user on
a system may be used to, and may set in their environment by default.
HAVE_VFORK=2 is clearly an autoconf symbol, that is only meant to be defined
by autoconf and tested by autoconfigurated packages.
Thus protecting _XXX_SOURCE seems perfectly legitimate, while protecting
HAVE_XXX seems effectively superfluous.
> 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.
I agree there and their definitions may be protected also, while one may
argue that if they are already defined by the user th etest below will find
them unuseful and would not define them :-).
>
> 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;
> }
>
Seems fine yes.
Regards,
Bernard
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
--------------------------------------------
