From owner-svn-src-all@FreeBSD.ORG Mon May 20 15:36:01 2013 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6507241A; Mon, 20 May 2013 15:36:01 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 28DC1139; Mon, 20 May 2013 15:36:00 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 4DC9B12339C; Tue, 21 May 2013 01:15:12 +1000 (EST) Date: Tue, 21 May 2013 01:15:11 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Stefan Farfeleder Subject: Re: svn commit: r250806 - head/sys/sys In-Reply-To: <20130520140304.GA1429@mole.fafoe.narf.at> Message-ID: <20130521004803.K8511@besplex.bde.org> References: <201305190744.r4J7i2FD055067@svn.freebsd.org> <20130519094813.GA1465@mole.fafoe.narf.at> <20130520140304.GA1429@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=BPvrNysG c=1 sm=1 a=ScYog2KUUbcA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=FSHVhTTuonsA:10 a=6I5d2MoRAAAA:8 a=3jfGjxefYG8Su_c3qMsA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: svn-src-head@FreeBSD.org, Ed Schouten , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 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: Mon, 20 May 2013 15:36:01 -0000 On Mon, 20 May 2013, Stefan Farfeleder wrote: > On Mon, May 20, 2013 at 01:06:50PM +0200, Ed Schouten wrote: >> Hi Stefan, >> >> 2013/5/19 Stefan Farfeleder : >>> Shouldn't we fix lint and our headers to use a different macro name? One >>> starting with __? >> >> Fixing lint: yes. Changing our macros to use a different name: no. > >> The reason why we had __volatile, __inline, etc. in the first place, >> was because adding definitions for volatile and inline directly would >> be against the standard, as these words can be used freely in > C11 only added keywords starting with _[A-Z], which is reserved by all >> the older standards, meaning we are completely free to define them in >> any way we like. Except when C11 or the compiler defines them. >> This specific breakage was unrelated to the naming of the keyword. The >> breakage existed, because existing tools do a build with -Dlint set. >> Because we use _Thread_local in our own header files already >> (runetype.h, I think), this caused a variable declared in a header >> file to be of the wrong kind (TLS vs non-TLS). Isn't this a bug in the tools too (if they define lint to get linting)? lint itself predefines lint, so defining it in source code seems wrong. Since it is not reserved, they can define it for their own purposes, but then it might interfere with actually running lint. >> In my opinion we should not add __[a-z] definitions for things that >> are part of C11. Doing this only makes our code less easily exportable >> to other systems. Only using reserved words (including new ones in C11) in applications gives unportability. Ones like __FBSDID() that are meant to be used shouldn't exist. > I think you misunderstood what I meant. We now have quiet a few > occurrences of `#ifdef lint' or equivalent in /usr/include. I think those > should be changed to `#ifdef __lint' to allow application code to do > > #define lint foo > #include > > which is perfectly fine POSIX code (at least to my knowledge) and should > not change the behaviour of the included header. lint actually predefines __LINT__, not __lint. Of course it is a bug that system headers depend on symbols in the application namespace like lint. My version never had the lint ifdef(s) in sys/cdefs.h. I don't like them for other reasons. They results in lint checking different source code to what the compiler sees. FreeBSD's lint barely supports C90, but C99 features like C99 initializers are now used extensively, at least in the kernel. Use of features like this can't be hidden from lint using a few ifdefs in headers. Bruce