This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: need to define _ISOC99_SOURCE


   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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]