<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 5, 2015 at 3:56 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">================<br>
Comment at: include/clang/Basic/DiagnosticCommonKinds.td:119<br>
@@ +118,3 @@<br>
+  InGroup<ImplicitlyUnsignedLiteral>;<br>
+def warn_old_implicitly_unsigned_long : Warning<<br>
+  "integer literal is of type unsigned long only when %select{C99|C++11}0 "<br>
----------------<br>
</span><span class="">hubert.reinterpretcast wrote:<br>
> rsmith wrote:<br>
> > In C++98, this should probably be an `ExtWarn` rather than a `Warning`, because this case has undefined behavior. Splitting this into two warnings would also allow you to put the warning into `-Wc99-compat` or `-Wc++11-compat` as appropriate, and to indicate that the C++98 case has undefined behavior.<br>
> In C++98, the undefined behaviour is only on the case of a decimal integer literal with none of `u`/`U`/`l`/`L`. If the `l`/`L` is present, the choice of `unsigned long` is required to be considered after `long`.<br>
><br>
> I agree that an `ExtWarn` is appropriate for the undefined behaviour case, but I do not think that the `-Wc99-compat`/`-Wc++11-compat` split still follows.<br>
</span>OK, so:<br>
<br>
 * For the cases where the code has undefined behavior, the warning should be an `ExtWarn`<br>
 * For the cases where the code has defined behavior but changes meaning in a later standard, the warning should be in `-Wc*-compat`<br>
 * For the cases where the code becomes invalid in a later standard, the warning should say so<br>
 * We should split this warning up into enough separate diagnostics that we can cover all of the above cases with correct, clear, helpful diagnostics<br>
<br>
I think the different cases are:<br>
<br>
 1) C89, no suffix or L, LONG_MAX == LLONG_MAX (c99-compat), "will be ill-formed in C99 onwards"<br>
 2) C89, no suffix or L, LONG_MAX < LLONG_MAX (c99-compat), "will have type 'long long' in C99 onwards"<br>
 3) C++98, no suffix, LONG_MAX == LLONG_MAX (c++11-compat, ExtWarn), "will be ill-formed in C++11 onwards"<br>
 4) C++98, L suffix, LONG_MAX == LLONG_MAX (c++11-compat), "will be ill-formed in C++11 onwards"<br>
 5) C++98, no suffix, LONG_MAX < LLONG_MAX (c++11-compat, ExtWarn), "will have type 'long long' in C++11 onwards"<br>
 6) C++98, L suffix, LONG_MAX < LLONG_MAX (c++11-compat), "will have type 'long long' in C++11 onwards"<br>
<br>
I think you can cover the above with three different diagnostics, for 1+2, 3+5, and 4+6, with a %select in each one selecting on whether 'long long' is large enough for the literal.<br></blockquote><div>Sounds good.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Each of these should be in either `-Wc99-compat` or `-Wc++11-compat` because the meaning of the program would be different under `-std=c99` or `-std=c++11`, respectively.<br>
<div class="HOEnZb"><div class="h5"><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D9794&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=BSqEv9KvKMW_Ob8SyngJ70KdZISM_ASROnREeq0cCxk&m=F6Hd2aDDc-4LYXF7WZByFoLrP195RQ5C6oYGbfwDKzY&s=A23giRNJDHsYy-l5CmnqqUAgRGamLhNI8-UhGm3Vd8E&e=" target="_blank">http://reviews.llvm.org/D9794</a><br>
<br>
EMAIL PREFERENCES<br>
  <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_settings_panel_emailpreferences_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=BSqEv9KvKMW_Ob8SyngJ70KdZISM_ASROnREeq0cCxk&m=F6Hd2aDDc-4LYXF7WZByFoLrP195RQ5C6oYGbfwDKzY&s=8E9gU51ejCcC7fLKO0D-RGcZDK7MZfYJ9-MWYsQIJNs&e=" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
<br>
<br>
</div></div></blockquote></div><br></div></div>