Date: Mon, 20 May 2013 16:03:04 +0200 From: Stefan Farfeleder <stefanf@FreeBSD.org> To: Ed Schouten <ed@80386.nl> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r250806 - head/sys/sys Message-ID: <20130520140304.GA1429@mole.fafoe.narf.at> In-Reply-To: <CAJOYFBC3Ww-jdy2cm7QNEbVzrZJHaeo3y797BVYp53pKJ5e-Nw@mail.gmail.com> References: <201305190744.r4J7i2FD055067@svn.freebsd.org> <20130519094813.GA1465@mole.fafoe.narf.at> <CAJOYFBC3Ww-jdy2cm7QNEbVzrZJHaeo3y797BVYp53pKJ5e-Nw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 20, 2013 at 01:06:50PM +0200, Ed Schouten wrote: > Hi Stefan, > > 2013/5/19 Stefan Farfeleder <stefanf@freebsd.org>: > > 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 <C99. > 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. > > 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). > > 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. Hi Ed, 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 <header.h> which is perfectly fine POSIX code (at least to my knowledge) and should not change the behaviour of the included header. Stefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130520140304.GA1429>