<div class="gmail_quote">David, I don't think is really the right approach...</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Fri, Mar 16, 2012 at 1:30 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":6xw">Suppress macro expansion of NULL in NULL warnings.<br></div></blockquote><div><br></div><div>This only suppresses it in one warning though, not in all warnings. I don't see why we don't want to always suppress the NULL macro expansion. I'd be interested in moving this into the logic for generating macro expansion notes themselves. We could potentially generalize it to other standard-defined macros if beneficial.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":6xw">For "int i = NULL;" we would produce:<br>
<br>
null.cpp:5:11: warning: implicit conversion of NULL constant to integer [-Wconversion]<br>
  int i = NULL;<br>
      ~   ^~~~<br>
null.cpp:1:14: note: expanded from macro 'NULL'<br>
\#define NULL __null<br>
              ^~~~~~<br>
<br>
But we really shouldn't trace that macro expansion back into the header, yet we<br>
still want macro back traces for code like this:<br>
<br>
\#define FOO NULL<br>
int i = FOO;<br>
<br>
or<br>
<br>
\#define FOO int i = NULL;<br>
FOO<br></div></blockquote><div><br></div><div>What about the case I'm more worried about:</div><div><br></div><div>#undef NULL<br>#define NULL FOO</div><div><br></div><div>We need to predicate this on the actual contents of the NULL macro.</div>
<div><br></div><div>Also, doing the checks you're already doing, much less my suggested extra checking, shouldn't be done if the diagnostic is suppressed for any reason, which would also argue for sinking it into the macro expansion layer.</div>
</div>