This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: the actual c9x patch
- To: Richard Henderson <rth at cygnus dot com>
- Subject: Re: the actual c9x patch
- From: Zack Weinberg <zack at rabi dot columbia dot edu>
- Date: Tue, 01 Dec 1998 09:12:03 -0500
- cc: gavin at cygnus dot com, egcs-patches at cygnus dot com
I skimmed this patch and have some comments:
Please #define something so the library can tell if it's in C89 or
C9x mode. _ISOC9X_SOURCE is what glibc uses right now, it may change
when the X becomes known.
It'd be nice to decouple tight conformance from the selection of
standard version:
-std=c9x -ansi -> conforming mode, C9x
-std=c89 -ansi -> conforming mode, C89
-std=c89 -> extended mode, C89
-std=c9x -> extended mode, C9x
-ansi -> same as -std=c89 -ansi
You might be doing this already, but it wasn't clear on a fast read.
The patch makes __func__ identical with __FUNCTION__, but this is
incorrect. __FUNCTION__ is "" outside functions; __func__ is an
undefined symbol outside functions.
What are the intended semantics of -std=gnu? In particular, is the
library expected to define only C9x stuff when -std=c9x?
zw