Date: Sun, 21 Jun 2015 13:37:46 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: Dimitry Andric <dim@FreeBSD.org>, David Chisnall <theraven@FreeBSD.org>, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r268137 - head/sys/sys Message-ID: <5587047A.2060007@FreeBSD.org> In-Reply-To: <20150622022837.D2823@besplex.bde.org> References: <201407020845.s628jRG5031824@svn.freebsd.org> <5BE3492F-86A0-4CE3-A27C-8DB5EB662C64@FreeBSD.org> <55842F16.5040608@FreeBSD.org> <D58BE060-870A-4D5E-AE46-D915D9CD6A0C@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5587047A.2060007>