Date: Sun, 21 Jun 2015 11:11:05 -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: <5586E219.2010805@FreeBSD.org> In-Reply-To: <20150622012426.S2603@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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? 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. Let's just admit it: the build is basically broken for older compilers and no one cares enough to fix them. (Not ideal, just what we have). Pedro.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5586E219.2010805>