From owner-svn-src-all@FreeBSD.ORG Sun Jun 21 18:43:32 2015 Return-Path: Delivered-To: svn-src-all@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 317563A7 for ; Sun, 21 Jun 2015 18:43:32 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm33-vm2.bullet.mail.bf1.yahoo.com (nm33-vm2.bullet.mail.bf1.yahoo.com [72.30.239.202]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E04C4C6 for ; Sun, 21 Jun 2015 18:43:31 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1434911860; bh=dZNTkF2jwui1Zb5bJzjYPZwkwJTOhOfyWI7ahigYdzU=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=L+53G3S1v9n8ehNYOUAPdpjIWqT0Ofw/kEn2D8c0o3bUHKmuJy9fPkanUeVSz8iM6IF+pOIveahG6qwJRTHUGnwg6BDgcqUj++1Q6TVcM0H8Zm3leAChnaLMjYvi0ZYYsmiRvaPcQRpo6FlMokDDlDDqo92Ew/HYM4uqx3zCsEZhsM76lyDAyzik5dDlV3zRZmU+D9632eei67w/ZaM5Z0Oa+m3P7vgjUp48wtOxqgtDo09CfjhGPFmqT0ICKxfk1ZpNB6LFKj18ayTgCUqLfHA75lRubLHsRcbZApc4KLQI07LMCKjhcRl54giCFzU01yUneBB8SfLeDTvlwb2hTw== Received: from [66.196.81.174] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jun 2015 18:37:40 -0000 Received: from [98.139.211.199] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jun 2015 18:37:40 -0000 Received: from [127.0.0.1] by smtp208.mail.bf1.yahoo.com with NNFMP; 21 Jun 2015 18:37:40 -0000 X-Yahoo-Newman-Id: 337703.1539.bm@smtp208.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DOKPOwcVM1mgNIhTVZrt.qefikIVjT1o.WxryRRTax9CoK5 074HVEPlqc0p2Q7IjaxBwtgTyVuEJ9WS.ORlHe43Uxa2Fb3jbynrcUVNQVxy NCju6x.KHeKqZHfM8T.T5rmVyPB9rbsN5oDGihmYu3QG9EQ850FiluK9Ka3m FiYwpx1BjunNXZ.51A0RfIKRI8c4.vFpDyy6CUKImA9c4iUtXNdEhBZb4FYZ RoNepGTSSPbeqJ91HymRv5TRiai7F66ZMl5wGmL7LoZt4jw2OqAFOJXBxI2Y D.2QyAdKogjGE85SgqKxygfNkUcqITKIfWw2oY73TW9HJCJyiKJWc3vgodZc nLU9Z3XZy0SwBO9Z2UB7QQu5w0c7yxvJG.X_lbyNLp3vsCNb5Mu5hJc3wcV0 QyedMc3wtaRGHZZ8Rr72.r5ORD8.Vn703P8OZQahv2Ztie785eL75sqknVK3 lV8yIvnoHMDtHft9Eu9VIdmE.3mWPytqPl79GLnq3jMXCwrkp8ci5RE4t0F3 _DE89_AsE1oUjhpuPs8cd2rC942pf_4N7 X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <5587047A.2060007@FreeBSD.org> Date: Sun, 21 Jun 2015 13:37:46 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Bruce Evans CC: Dimitry Andric , David Chisnall , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r268137 - head/sys/sys References: <201407020845.s628jRG5031824@svn.freebsd.org> <5BE3492F-86A0-4CE3-A27C-8DB5EB662C64@FreeBSD.org> <55842F16.5040608@FreeBSD.org> <20150620023835.N2562@besplex.bde.org> <55861046.4050501@FreeBSD.org> <20150621154332.U976@besplex.bde.org> <5586CBCE.2010608@FreeBSD.org> <20150622012426.S2603@besplex.bde.org> <5586E219.2010805@FreeBSD.org> <20150622022837.D2823@besplex.bde.org> In-Reply-To: <20150622022837.D2823@besplex.bde.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2015 18:43:32 -0000 On 06/21/15 11:48, Bruce Evans wrote: > On Sun, 21 Jun 2015, Pedro Giffuni wrote: > >> On 06/21/15 10:41, Bruce Evans wrote: >>> On Sun, 21 Jun 2015, Pedro Giffuni wrote: >>> >>>> On 06/21/15 01:09, Bruce Evans wrote: >>>>> On Sat, 20 Jun 2015, Pedro Giffuni wrote: >>>> * ... >>>>>> With the patch we would use: >>>>>> >>>>>> __Noreturn void >>>>>> foo(void) _dead2; >>>>>> >>>>>> Which is still ugly but C11-ish. >>>>> >>>>> That asks for the same problems as defining __weak. >>>>> >>>>> Why not just don't use _Noreturn? It is an unimprovement on the gcc >>>>> attribute. The attribute works at the beginning or end, while >>>>> Noreturn >>>>> only works at the end. >>>> >>>> As I see it, newer (C11) software is likely to use _Noreturn in their >>>> headers >>> >>> We can define _Noreturn to support this (but possibly shouldn't). >>> >>> The newer software many be pure C11. Then it doesn't need any >>> definition, >>> and just doesn't compile with non-C11 compilers. >> >> Well, the fact this we just do this in the tree and no one has >> bothered to >> "clean" the situation for older compilers just indicates that no one >> *cares* >> about older compilers. > > No, we don't do this with older compilers, except for for a couple of > pre-C90 cases. We are careful to only define names in our namespace, > e.g., __signed but not the C90 keyword 'signed'. This is still fragile. > __signed is a keyword for gcc, and it is confusing that some of our use > of it require it to have the gcc meaning. __signed is in the > implementation > namespace so we don't own it completely. This is what is now causing > problems > with defining __weak. > We have plenty of C++-style comments and C99 initializers in the tree. We also use gcc constructor and destructor attributes. We can pretend we are supporting a lot of stuff, including the intel C compiler, which AFAICT was hacked to produce FreeBSD binaries but was never really native, but the truth is 100% portability has never been there. We just support what ever compiler was used to build FreeBSD at the time. > The situation with older compilers has not been cleaned because it either > works or is not used. Since it did work with older compilers when it was > written, the only way it can not still work is because of "cleaning" it > combined with null testing and null use so that bugs in the "cleaning" > are not detected. > >>> If we defined _Noreturn, it would be to use it in non-C11 software, >>> like >>> we do in stdlib.h. This is a fragile compatibility hack so it should >>> be avoided if possible. We can easily avoid it in our own headers by >>> not changing anything. Just use the old declaration, with __dead2 >>> placed >>> at the end. Any reasonable implementation of __attribute__() must >>> be able >>> to support any new attribute that a new standard might add. >> >> The thing is, why bother with gnuisms at all? > > There is no other way to declare necessary attributes that > __attribute__(()). > Not even __attribute__() like I wrote above -- that is just a syntax > error > since it is missing parentheses. __attribute__(()) is now a de-facto > standard for gnuish compilers, but it is not in any C standard and has > little chance of working with Microsoft compilers. It must be wrapped > in a #define like we do. > I mean really old gnuisms. We accommodate just fine for gcc 4.x and clang drew the line in gcc-4.2. Anything before that we should just deprecate, Anything after that we can work out relatively easy. >> I am personally OK with making it easier for everyone to use more >> modern constructs but I am not going out of my way to support >> gcc-1 or gcc-2. > > From there, it is only a small step to not supporting any compiler > except the current version of gcc (not even clang). > I agree it would not be impossible to support older compilers and leave space for bare standard ones, but perhaps it would be more realistic to draw a line somewhere and have a list of supported compilers. And if some FreeBSD consumers need a specific compiler it would be great to have them involved in the project. Pedro.