Date: Fri, 9 Jan 2009 16:07:50 +0100 From: Roman Divacky <rdivacky@freebsd.org> To: Christoph Mallon <christoph.mallon@gmx.de> Cc: Andrew Reilly <andrew-freebsd@areilly.bpc-users.org>, freebsd-current@freebsd.org, Ollivier Robert <roberto@keltia.freenix.fr> Subject: Re: gcc 4.3: when will it become standard compiler? Message-ID: <20090109150750.GA50331@freebsd.org> In-Reply-To: <49676598.7040708@gmx.de> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <20090109143339.GA45569@freebsd.org> <49676598.7040708@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 09, 2009 at 03:56:24PM +0100, Christoph Mallon wrote: > Roman Divacky schrieb: > >On Fri, Jan 09, 2009 at 03:28:20PM +0100, Christoph Mallon wrote: > >>Roman Divacky schrieb: > >>>On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote: > >>>>Roman Divacky schrieb: > >>>>>>I'm not saying it's wrong to look for alternatives, but you cannot > >>>>>>just change your system compiler like you change underwear. > >>>>>well... the first step is imho starting to compile world with C99... > >>>>>that might reveal some bugs, note that as of a few months ago > >>>>>8-current compiles cleanly with C99, that does not mean that it's > >>>>>working when you run those programs correctly :) > >>>>One step in the right direction is embracing the nice features modern C > >>>>offers you. For example declaring a variable right were you need it > >>>>instead of dozens of lines away is one such nice thing which improves > >>>>readability. Designated initializers improve readability, too. > >>>>But I'm not exactly sure what you mean by "compile world with C99". C99 > >>>>is pretty much backwards compatible to C89. > >>>sorry for the bad wording - I meant to turn C99 compilation on default. > >>>We compile in gnu89 mode now. > >>I still have no idea what you mean. Sure, you can specify -std=c99 (or > >>more likely gnu99), but an int is still an int - what do you expect? In > >>fact default mode of GCC accepts many C99 constructs like // comments > >>and mixed declarations and code, which are not valid C89. > > > >for example __restricted is C99 thing and there are others, I want this > > __restrict (not __restricted) is a GCC extension. The C99 spelling is > restrict. GCC also accepts __restrict__. Further, you should be *very* > careful with the restrict qualifier, because its exact semantic is > non-trivial (?6.7.3.1, it's one page of standardese speak). > But I see no problem for existing code in this respect. C99 mostly only > adds new language constructs. Only very few were removed. E.g. implicit > int was removed, but GCC still accepts it (and I guess clang too, > cpareser does). my point is that in C89 mode *restrict* (in whatever spelling) got expanded to nothing. we had a bug (typo in fact) related to *restrict* and we didnt catch it because of C89 compilation mode... thats my point (and the *restrict* thing is just an example) > >because clang for example defaults to C99 (in fact gnu99 as they support > >gnu extensions on default). By switching to default compilation in C99 > > >mode we can be sure we stay compatible with clang and others.... > > I'm pretty sure clang also accepts __restrict. > A compiler, which does not support most GCC extensions (inline assembler > being the most important) has no chance anyway. yes.... the problem is (was?) that clang is C99 on default while gcc is C89 on default. > >for example opensolaris seems to use C99 features which are not enabled > >in our world because of this (I found same assert() related stuff) etc. > > assert() predates C99. The only C99 specific aspect about assert(), that > I'm aware of, is, that C99 guarantees that the name of the function is > printed. they had code like <pseudocode> #if C99 #define __assert(..) something #else #define __assert(..) something_else #endif </pseudocode> my point is that we might have bugs in the C99 code that other (non-gcc) compilers expose and it's a good thing to unite on one standard. ie. C99 :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090109150750.GA50331>