[PATCH] Handle gcc -std=c99 -D_XOPEN_SOURCE=600 [BZ #284]

[PATCH] Handle gcc -std=c99 -D_XOPEN_SOURCE=600 [BZ #284]

[Jakub Jelinek]

Hi!

The c99 script (which is part of XPG6) uses gcc -std=c99.
Unfortunately -std=c99 defines also __STRICT_ANSI__ and
eventhough -D_XOPEN_SOURCE=600 per XPG6 should enable -D_POSIX_SOURCE
and -D_POSIX_C_SOURCE=200112L, when __STRICT_ANSI__ it doesn't do so.

I think it would be better if gcc -std=c99 did not define __STRICT_ANSI__,
only gcc -std=c99 -ansi did, because otherwise there is no way to
request ISO C99 language features and XPG6, but not GNU C99 language
extensions.

The c99 script could be changed to use gcc -std=c99 -U__STRICT_ANSI "$@",
but still there are many people who will use
gcc -std=c99 -D_XOPEN_SOURCE=600.

Or as done in the patch below __STRICT_ANSI__ can be ignored if
_XOPEN_SOURCE is defined for the purpose of defining _POSIX_SOURCE
and _POSIX_C_SOURCE.

The __clockid_t change is IMHO useful no matter what solution is chosen,
NPTL pthread.h already uses __clockid_t in a couple of other places
surrounded by __USE_XOPEN2K.

2004-07-23  Jakub Jelinek  <jakub@redhat.com>

	[BZ #284]
	* include/features.h (_POSIX_SOURCE, _POSIX_C_SOURCE): Define
	if _XOPEN_SOURCE >= 500 even if __STRICT_ANSI__ is defined.
linuxthreads/
	* sysdeps/pthread/pthread.h (pthread_getcpuclockid): Use __clockid_t
	instead of clockid_t.
nptl/
	* sysdeps/pthread/pthread.h (pthread_getcpuclockid): Use __clockid_t
	instead of clockid_t.

--- libc/include/features.h.jj	2003-05-17 02:38:00.000000000 +0200
+++ libc/include/features.h	2004-07-23 20:12:52.086150557 +0200
@@ -162,8 +162,8 @@
 
 /* If none of the ANSI/POSIX macros are defined, use POSIX.1 and POSIX.2
    (and IEEE Std 1003.1b-1993 unless _XOPEN_SOURCE is defined).  */
-#if (!defined __STRICT_ANSI__ && !defined _POSIX_SOURCE && \
-     !defined _POSIX_C_SOURCE)
+#if ((!defined __STRICT_ANSI__ || (_XOPEN_SOURCE - 0) >= 500) && \
+     !defined _POSIX_SOURCE && !defined _POSIX_C_SOURCE)
 # define _POSIX_SOURCE	1
 # if defined _XOPEN_SOURCE && (_XOPEN_SOURCE - 0) < 500
 #  define _POSIX_C_SOURCE	2
--- libc/linuxthreads/sysdeps/pthread/pthread.h.jj	2003-12-29 00:50:52.000000000 +0100
+++ libc/linuxthreads/sysdeps/pthread/pthread.h	2004-07-23 18:59:27.759397642 +0200
@@ -648,7 +648,7 @@ extern void _pthread_cleanup_pop_restore
 #ifdef __USE_XOPEN2K
 /* Get ID of CPU-time clock for thread THREAD_ID.  */
 extern int pthread_getcpuclockid (pthread_t __thread_id,
-				  clockid_t *__clock_id) __THROW;
+				  __clockid_t *__clock_id) __THROW;
 #endif
 
 
--- libc/nptl/sysdeps/pthread/pthread.h.jj	2004-03-22 14:45:56.000000000 +0100
+++ libc/nptl/sysdeps/pthread/pthread.h	2004-07-23 18:58:50.252951923 +0200
@@ -915,7 +915,7 @@ extern int pthread_setspecific (pthread_
 #ifdef __USE_XOPEN2K
 /* Get ID of CPU-time clock for thread THREAD_ID.  */
 extern int pthread_getcpuclockid (pthread_t __thread_id,
-				  clockid_t *__clock_id) __THROW;
+				  __clockid_t *__clock_id) __THROW;
 #endif
 
 

	Jakub

Re: [PATCH] Handle gcc -std=c99 -D_XOPEN_SOURCE=600 [BZ #284]

[Ulrich Drepper]

Joseph S. Myers wrote:

> A conforming implementation of a c99 script (none is included in FSF GCC,
> though it's in the projects list and several variants are floating around)
> should certainly define __STRICT_ANSI__ so that pure ISO C programs that
> don't want POSIX facilities can be built with it and programs using POSIX
> facilities need to define feature test macros.

Wrong.  That would mean you would hijack the name "c99".  c99 is the
name of the C compiler in POSIX.  Any other use, e.g., for strict ISO C
compliant uses, is a conflict.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

Re: [PATCH] Handle gcc -std=c99 -D_XOPEN_SOURCE=600 [BZ #284]

[Ulrich Drepper]

Joseph S. Myers wrote:

> c99 is the name of the compiler to "accept source code conforming to the
> ISO C standard".  For example,

And once -D_POSIX_C_SOURCE=200112L is defined all this ISO C nonsense
must be completely out of the way.  No __STRICT_ANSI__, since non-ISO C
stuff is used.  The same applies to a few other defines.  Only if none
is defined can this silly strict ISO C business take place.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

Re: [PATCH] Handle gcc -std=c99 -D_XOPEN_SOURCE=600 [BZ #284]

[Jakub Jelinek]

On Fri, Jul 23, 2004 at 01:19:46PM -0700, Ulrich Drepper wrote:
> Joseph S. Myers wrote:
> 
> > c99 is the name of the compiler to "accept source code conforming to the
> > ISO C standard".  For example,
> 
> And once -D_POSIX_C_SOURCE=200112L is defined all this ISO C nonsense
> must be completely out of the way.  No __STRICT_ANSI__, since non-ISO C
> stuff is used.  The same applies to a few other defines.  Only if none
> is defined can this silly strict ISO C business take place.

I guess it all depends what exact meaning __STRICT_ANSI__ is supposed to have.
Either its definition chooses only ISO C90 (resp. C99) features in the
headers, or it can be combined with other feature set macros with the result
of a union between ISO C90 (resp. C99) features and features selected by
the other feature macros.
The __STRICT_ANSI__ documentation in info gcc doesn't seem to favor either
of these definitions, at least in my reading.

	Jakub

Re: [PATCH] Handle gcc -std=c99 -D_XOPEN_SOURCE=600 [BZ #284]

[Roland McGrath]

> On Fri, Jul 23, 2004 at 01:19:46PM -0700, Ulrich Drepper wrote:
> > Joseph S. Myers wrote:
> > 
> > > c99 is the name of the compiler to "accept source code conforming to the
> > > ISO C standard".  For example,
> > 
> > And once -D_POSIX_C_SOURCE=200112L is defined all this ISO C nonsense
> > must be completely out of the way.  No __STRICT_ANSI__, since non-ISO C
> > stuff is used.  The same applies to a few other defines.  Only if none
> > is defined can this silly strict ISO C business take place.
> 
> I guess it all depends what exact meaning __STRICT_ANSI__ is supposed to have.
> Either its definition chooses only ISO C90 (resp. C99) features in the
> headers, or it can be combined with other feature set macros with the result
> of a union between ISO C90 (resp. C99) features and features selected by
> the other feature macros.
> The __STRICT_ANSI__ documentation in info gcc doesn't seem to favor either
> of these definitions, at least in my reading.

I think this bit here:

     The `-ansi' option does not cause non-ISO programs to be rejected
     gratuitously.  For that, `-pedantic' is required in addition to
     `-ansi'.  *Note Warning Options::.

leans in the direction of allow combination of -ansi with feature macros.
However, I think it is also reasonable to say that -ansi is a bit archaic.
The important useful case is when someone wants to compile their program
and ensure it is strictly conformant to POSIX, i.e. using non-ISO-C
interfaces specified by POSIX, but not using C language extensions.  As I
understand it, this is supported just fine with -std=c99
-D_POSIX_C_SOURCE=something.  So I don't off hand see the need for people
to use -ansi.