From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 15:53:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BBFF106567A for ; Fri, 9 Jan 2009 15:53:13 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id DD49E8FC29 for ; Fri, 9 Jan 2009 15:53:11 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 09 Jan 2009 15:53:10 -0000 Received: from p54A3E499.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.228.153] by mail.gmx.net (mp071) with SMTP; 09 Jan 2009 16:53:10 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/X0y8ffUzXn+JRZ0DRHkWp+uJdJXFztCxrOVOvfx HgWQeaL5vSAupf Message-ID: <496772E1.2050504@gmx.de> Date: Fri, 09 Jan 2009 16:53:05 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Roman Divacky 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> <20090109150750.GA50331@freebsd.org> In-Reply-To: <20090109150750.GA50331@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: Andrew Reilly , freebsd-current@freebsd.org, Ollivier Robert Subject: Re: gcc 4.3: when will it become standard compiler? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 15:53:13 -0000 Roman Divacky schrieb: > 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... Ah, you mean a simple syntax error like char __restrict* a instead of char* __restrict a. I thought you meant something serious like different behaviour between the standards. Why somebody would #define away __restrict (or #define away any other extension, which GCC accepts anyway) is beyond me. If the source code already contains distinctions between C89 and C99 then, imo, somebody did something wrong. > 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 > > > #if C99 > #define __assert(..) something > #else > #define __assert(..) something_else > #endif > This is probably, as mentioned above, because C89 does not have __func__. > 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 :) In general I agree: C99 should be used as language standard for compilation. style(9) needs some updates for this, too.