This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: need to define _ISOC99_SOURCE
- To: akim at epita dot fr
- Subject: Re: need to define _ISOC99_SOURCE
- From: Paul Eggert <eggert at twinsun dot com>
- Date: Tue, 1 Aug 2000 11:20:28 -0700 (PDT)
- CC: haible at ilog dot fr, jsm28 at cam dot ac dot uk, libc-alpha at sourceware dot cygnus dot com, autoconf at gnu dot org
- References: <Pine.SOL.4.21.0007261506580.6571-100000@red.csi.cam.ac.uk><m3lmyoamkf.fsf@otr.mynet.cygnus.com><200007262030.NAA15438@ruby.twinsun.com><14719.22225.713527.823418@honolulu.ilog.fr><mv4vgxrx6ki.fsf@nostromo.lrde.epita.fr><200007271634.JAA08859@green-office.twinsun.com><mv4n1iymwrq.fsf@nostromo.lrde.epita.fr><14725.40424.405013.773855@honolulu.ilog.fr><mv466pme1pc.fsf@nostromo.lrde.epita.fr><200007312139.OAA01047@ruby.twinsun.com> <mv43dkpnk3p.fsf@nostromo.lrde.epita.fr>
From: Akim Demaille <akim@epita.fr>
Date: 01 Aug 2000 16:15:22 +0200
Here is a satisfying starting point? OK to commit?
Not yet, unfortunately, and partly this is due to inadequate research
on my part; please see below. (Sorry about that.)
First, some preliminary comments:
- There's a good posting by Steve Summit in comp.lang.c about these
macros in <http://deja.com/=dnc/getdoc.xp?AN=614050311>. He writes
"For your own sanity, pay as little attention to these #defines as
you can. (Seriously.)". I tend to agree.
- Bernard Dautrevaux's comments on why feature-test macros should not
be defined if the user has already defined them makes sense to me,
particularly since HP "cc -Ae" apparently predefines _HPUX_SOURCE.
So let's do it that way.
The most important problem in that "starting-point" patch is with
_XOPEN_SOURCE, but there are also problems with the other macros.
That patch defines _XOPEN_SOURCE to 500 unless doing so would break
fileno. But that wasn't the algorithm I suggested: I suggested
defining _XOPEN_SOURCE to 500 only if that change causes <stdio.h> to
declare ftello.
I did a little more research this morning, and discovered that
defining _XOPEN_SOURCE to 500 removes some symbols in Solaris and
defines some others. For example, defining _XOPEN_SOURCE=500 affects
Solaris 8 <stdio.h> by removing these declarations:
FILE *fopen64(const char *, const char *);
FILE *freopen64(const char *, const char *, FILE *);
FILE *tmpfile64(void);
int fgetpos64(FILE *, fpos64_t *);
int fseeko64(FILE *, off64_t, int);
int fsetpos64(FILE *, const fpos64_t *);
int getsubopt(char **, char *const *, char **);
int setlinebuf(FILE *);
off64_t ftello64(FILE *);
typedef __longlong_t fpos64_t;
typedef __longlong_t off64_t;
typedef long long __longlong_t;
void setbuffer(FILE *, char *, size_t);
and adding these declarations:
int ftrylockfile(FILE *);
int getc_unlocked(FILE *);
int getchar_unlocked(void);
int putc_unlocked(int, FILE *);
int putchar_unlocked(int);
typedef __va_list va_list;
void flockfile(FILE *);
void funlockfile(FILE *);
Some autoconfed programs may want the former set of symbols, and some
may want the latter. Therefore, _XOPEN_SOURCE shouldn't be defined
willy-nilly; it should be defined only by specific macros (like
AC_SYS_LARGEFILE) that need it for a specific purpose. So I would not
attempt to define _XOPEN_SOURCE globally.
This raises the issue of deciding what value to set _XOPEN_SOURCE to
when configure.in invokes two specialized macros that want to set
_XOPEN_SOURCE to different values. I don't know any place that this
happens yet, but it might. I would say that the first value should
win. In any case, the losing macro should do the right thing (e.g.,
do not define HAVE_FTELLO if the winning _XOPEN_SOURCE value doesn't
declare ftello).
_POSIX_SOURCE and _POSIX_C_SOURCE have problems similar to
_XOPEN_SOURCE. On Solaris 8 at least, they both declare and
"undeclare" symbols. So setting these should be be avoided if
possible as well; it should be relegated to specific macros that
really need it.
As far as I know, it's OK to define _GNU_SOURCE, _ALL_SOURCE,
__EXTENSIONS__, _HPUX_SOURCE, and _MINIX, unless they are already
defined. However, maintainers may be confused by this ("what? you're
definining _MINIX on a Solaris host???") so to avoid confusion it
would be better to define these symbols only if necessary.
Here's an idea for doing this:
Run "$CC -E" on a trivial program that only includes standard headers
like <stdio.h> and <sys/types.h>. Then, run "$CC -E -D_GNU_SOURCE" on
the same input. If the output differs, then define _GNU_SOURCE;
otherwise, don't bother. Similarly for _ALL_SOURCE, __EXTENSIONS__,
_HPUX_SOURCE, and _MINIX.
+ -D_GNU_SOURCE=1 \
This is just a minor point, but is the "=1" really needed here?
-Dx is equivalent to -Dx=1 on all compilers that I've ever heard of.