* [PATCH] Handle gcc -std=c99 -D_XOPEN_SOURCE=600 [BZ #284] @ 2004-07-23 18:25 Jakub Jelinek [not found] ` <Pine.LNX.4.58.0407231837590.691@digraph.polyomino.org.uk> 0 siblings, 1 reply; 5+ messages in thread From: Jakub Jelinek @ 2004-07-23 18:25 UTC (permalink / raw) To: Ulrich Drepper, Joseph S. Myers; +Cc: Glibc hackers 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <Pine.LNX.4.58.0407231837590.691@digraph.polyomino.org.uk>]
* Re: [PATCH] Handle gcc -std=c99 -D_XOPEN_SOURCE=600 [BZ #284] [not found] ` <Pine.LNX.4.58.0407231837590.691@digraph.polyomino.org.uk> @ 2004-07-23 19:16 ` Ulrich Drepper [not found] ` <Pine.LNX.4.58.0407231933390.9727@digraph.polyomino.org.uk> 0 siblings, 1 reply; 5+ messages in thread From: Ulrich Drepper @ 2004-07-23 19:16 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Jakub Jelinek, Glibc hackers 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 â ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <Pine.LNX.4.58.0407231933390.9727@digraph.polyomino.org.uk>]
* Re: [PATCH] Handle gcc -std=c99 -D_XOPEN_SOURCE=600 [BZ #284] [not found] ` <Pine.LNX.4.58.0407231933390.9727@digraph.polyomino.org.uk> @ 2004-07-23 20:20 ` Ulrich Drepper 2004-07-30 7:58 ` Jakub Jelinek 0 siblings, 1 reply; 5+ messages in thread From: Ulrich Drepper @ 2004-07-23 20:20 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Jakub Jelinek, Glibc hackers 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 â ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Handle gcc -std=c99 -D_XOPEN_SOURCE=600 [BZ #284] 2004-07-23 20:20 ` Ulrich Drepper @ 2004-07-30 7:58 ` Jakub Jelinek 2004-08-02 20:47 ` Roland McGrath 0 siblings, 1 reply; 5+ messages in thread From: Jakub Jelinek @ 2004-07-30 7:58 UTC (permalink / raw) To: Ulrich Drepper; +Cc: Joseph S. Myers, Glibc hackers 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Handle gcc -std=c99 -D_XOPEN_SOURCE=600 [BZ #284] 2004-07-30 7:58 ` Jakub Jelinek @ 2004-08-02 20:47 ` Roland McGrath 0 siblings, 0 replies; 5+ messages in thread From: Roland McGrath @ 2004-08-02 20:47 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Ulrich Drepper, Joseph S. Myers, Glibc hackers > 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-08-02 20:47 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-07-23 18:25 [PATCH] Handle gcc -std=c99 -D_XOPEN_SOURCE=600 [BZ #284] Jakub Jelinek [not found] ` <Pine.LNX.4.58.0407231837590.691@digraph.polyomino.org.uk> 2004-07-23 19:16 ` Ulrich Drepper [not found] ` <Pine.LNX.4.58.0407231933390.9727@digraph.polyomino.org.uk> 2004-07-23 20:20 ` Ulrich Drepper 2004-07-30 7:58 ` Jakub Jelinek 2004-08-02 20:47 ` Roland McGrath
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).