<div dir="ltr">You can look at the warnings this produces for Chromium in a clang-cl build here: <a href="http://build.chromium.org/p/chromium.fyi/builders/CrWinClang/builds/832/steps/compile/logs/stdio">http://build.chromium.org/p/chromium.fyi/builders/CrWinClang/builds/832/steps/compile/logs/stdio</a> (search for "warning(clang)").<div><br></div><div>Examples:</div><div><br></div><div>It warns on libopenjpeg defining restrict to nothing if C99 isn't enabled:</div><div><br></div><div><div>#if (__STDC_VERSION__ != 199901L)</div><div><span class="" style="white-space:pre"> </span>/* Not a C99 compiler */</div><div><span class="" style="white-space:pre"> </span>#ifdef __GNUC__</div><div><span class="" style="white-space:pre"> </span>#define restrict __restrict__</div><div><span class="" style="white-space:pre"> </span>#else</div><div><span class="" style="white-space:pre"> </span>#define restrict /* restrict */</div><div><span class="" style="white-space:pre"> </span>#endif</div><div>#endif</div></div><div><br></div><div>It warns on libusb defining inline to __inline:</div><div><br></div><div><div>#ifdef _MSC_VER</div><div>/* on MS environments, the inline keyword is available in C++ only */</div><div>#if !defined(__cplusplus)</div><div>#define inline __inline</div><div>#endif</div></div><div><br></div><div>Similar for expat:</div><div><br></div><div><div>#ifdef __cplusplus</div><div>#define inline inline</div><div>#else</div><div>#ifndef inline</div><div>#define inline</div><div>#endif</div><div>#endif</div></div><div><br></div><div>And qcms:</div><div><br></div><div><div>#ifdef _MSC_VER</div><div>#define inline _inline</div><div>#endif</div></div><div><br></div><div>And mesa:</div><div><br></div><div><div>#ifndef inline</div><div># ifdef __cplusplus</div><div> /* C++ supports inline keyword */</div><div>// ...</div><div># elif defined(_MSC_VER)</div><div># define inline __inline</div></div><div><br></div><div>harfbuzz does this for inline too.</div><div><br></div><div><br></div><div>re2 defines final, but with arguments:</div><div><br></div><div><div>#define final(a,b,c) some_computation(a, b,c )</div></div><div><br></div><div><br></div><div>To me, this doesn't look very useful. I'm not sure it should be on by default</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 9:26 AM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Dec 15, 2014 at 11:47:23AM -0500, Aaron Ballman wrote:<br>
> On Mon, Dec 15, 2014 at 11:35 AM, Joerg Sonnenberger<br>
> <<a href="mailto:joerg@britannica.bec.de">joerg@britannica.bec.de</a>> wrote:<br>
> > On Mon, Dec 15, 2014 at 11:32:02AM -0500, Aaron Ballman wrote:<br>
> >> On Sat, Dec 13, 2014 at 2:46 PM, Joerg Sonnenberger<br>
> >> > (2) #define restrict __restrict__ --> code that has to deal with pre-C99<br>
> >> > default in GCC.<br>
> >><br>
> >> I'm not certain this should have triggered the warning in the first<br>
> >> place. Either restrict is a keyword (at which point, the #define<br>
> >> should be considered possibly harmful), or restrict isn't a keyword<br>
> >> (and then there's no reason for the warning in the first place).<br>
> ><br>
> > It happens in code that has to deal with different compilers. Consider a<br>
> > pre-generated config.h. In NetBSD we have to deal with different GCC<br>
> > versions and Clang, at least the former doesn't default to C99 :(<br>
><br>
> I'm confused. Are you talking about vendors where restrict is a<br>
> keyword, but it's not implemented (properly)?<br>
<br>
</span>configure will not pick it up for GCC with the C90 default.<br>
<span class=""><br>
> >> > (3) #define extern, #define static --> debug, code sharing<br>
> >><br>
> >> I think these should be a warning. If you're doing a debug build where<br>
> >> you want to turn off keywords, you can add a -Wno-keyword-macro flag<br>
> >> to your command line.<br>
> ><br>
> > I disagree. Having to change the warning settings just to get a debug<br>
> > build to work is stupid.<br>
><br>
> Redefining keywords to be empty macros in production code is equally stupid. ;-)<br>
><br>
> > My question remains: what bugs has this warning caught? I've heard that<br>
> > Microsoft believes this to be reasonable to warn about, but that's about<br>
> > it.<br>
><br>
> CERT also feels this is reasonable to diagnose:<br>
</span>> ...<br>
<br>
Well, keep in mind that C and restricted interface contracts don't<br>
necessarily agree with each other, so often various tricks are played.<br>
So summarize, I think the following should be accepted silently by<br>
default:<br>
<br>
(1) macro name equals macro body.<br>
(2) macro name is a "storage" class keyword (extern, static, inline) and<br>
the body is empty.<br>
(3) macro name is const.<br>
(4) macro body wrapped with __ equals macro name.<br>
<span class="HOEnZb"><font color="#888888"><br>
Joerg<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div></div>