r224012 - Emit warning if define or undef reserved identifier or keyword.

[Nico Weber]

You can look at the warnings this produces for Chromium in  a clang-cl
build here:
http://build.chromium.org/p/chromium.fyi/builders/CrWinClang/builds/832/steps/compile/logs/stdio
(search for "warning(clang)").

Examples:

It warns on libopenjpeg defining restrict to nothing if C99 isn't enabled:

#if (__STDC_VERSION__ != 199901L)
/* Not a C99 compiler */
#ifdef __GNUC__
#define restrict __restrict__
#else
#define restrict /* restrict */
#endif
#endif

It warns on libusb defining inline to __inline:

#ifdef _MSC_VER
/* on MS environments, the inline keyword is available in C++ only */
#if !defined(__cplusplus)
#define inline __inline
#endif

Similar for expat:

#ifdef __cplusplus
#define inline inline
#else
#ifndef inline
#define inline
#endif
#endif

And qcms:

#ifdef _MSC_VER
#define inline _inline
#endif

And mesa:

#ifndef inline
#  ifdef __cplusplus
     /* C++ supports inline keyword */
// ...
#  elif defined(_MSC_VER)
#    define inline __inline

harfbuzz does this for inline too.


re2 defines final, but with arguments:

#define final(a,b,c) some_computation(a, b,c )


To me, this doesn't look very useful. I'm not sure it should be on by
default

On Mon, Dec 15, 2014 at 9:26 AM, Joerg Sonnenberger <joerg at britannica.bec.de
> wrote:
>
> On Mon, Dec 15, 2014 at 11:47:23AM -0500, Aaron Ballman wrote:
> > On Mon, Dec 15, 2014 at 11:35 AM, Joerg Sonnenberger
> > <joerg at britannica.bec.de> wrote:
> > > On Mon, Dec 15, 2014 at 11:32:02AM -0500, Aaron Ballman wrote:
> > >> On Sat, Dec 13, 2014 at 2:46 PM, Joerg Sonnenberger
> > >> > (2) #define restrict __restrict__ --> code that has to deal with
> pre-C99
> > >> > default in GCC.
> > >>
> > >> I'm not certain this should have triggered the warning in the first
> > >> place. Either restrict is a keyword (at which point, the #define
> > >> should be considered possibly harmful), or restrict isn't a keyword
> > >> (and then there's no reason for the warning in the first place).
> > >
> > > It happens in code that has to deal with different compilers. Consider
> a
> > > pre-generated config.h. In NetBSD we have to deal with different GCC
> > > versions and Clang, at least the former doesn't default to C99 :(
> >
> > I'm confused. Are you talking about vendors where restrict is a
> > keyword, but it's not implemented (properly)?
>
> configure will not pick it up for GCC with the C90 default.
>
> > >> > (3) #define extern, #define static --> debug, code sharing
> > >>
> > >> I think these should be a warning. If you're doing a debug build where
> > >> you want to turn off keywords, you can add a -Wno-keyword-macro flag
> > >> to your command line.
> > >
> > > I disagree. Having to change the warning settings just to get a debug
> > > build to work is stupid.
> >
> > Redefining keywords to be empty macros in production code is equally
> stupid. ;-)
> >
> > > My question remains: what bugs has this warning caught? I've heard that
> > > Microsoft believes this to be reasonable to warn about, but that's
> about
> > > it.
> >
> > CERT also feels this is reasonable to diagnose:
> > ...
>
> Well, keep in mind that C and restricted interface contracts don't
> necessarily agree with each other, so often various tricks are played.
> So summarize, I think the following should be accepted silently by
> default:
>
> (1) macro name equals macro body.
> (2) macro name is a "storage" class keyword (extern, static, inline) and
> the body is empty.
> (3) macro name is const.
> (4) macro body wrapped with __ equals macro name.
>
> Joerg
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141215/851c9619/attachment.html>