From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 14:56:28 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 BE3A6106566B for ; Fri, 9 Jan 2009 14:56:28 +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 058878FC1D for ; Fri, 9 Jan 2009 14:56:27 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 09 Jan 2009 14:56:26 -0000 Received: from p54A3E499.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.228.153] by mail.gmx.net (mp052) with SMTP; 09 Jan 2009 15:56:26 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/uX3cRwRXuFyV8RNkJ4GzSqwDvTQ/a5k1Qn9MMTN LyZCmvmHc+0oyN Message-ID: <49676598.7040708@gmx.de> Date: Fri, 09 Jan 2009 15:56:24 +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> In-Reply-To: <20090109143339.GA45569@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 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 14:56:29 -0000 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). > 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. > 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.