[PATCH] Consider unsigned long for non-u/U decimal literals (C90/C++03)

[Hubert Tong]

On Fri, Jun 5, 2015 at 3:56 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> ================
> Comment at: include/clang/Basic/DiagnosticCommonKinds.td:119
> @@ +118,3 @@
> +  InGroup<ImplicitlyUnsignedLiteral>;
> +def warn_old_implicitly_unsigned_long : Warning<
> +  "integer literal is of type unsigned long only when %select{C99|C++11}0
> "
> ----------------
> hubert.reinterpretcast wrote:
> > rsmith wrote:
> > > 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.
> > 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`.
> >
> > 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.
> OK, so:
>
>  * For the cases where the code has undefined behavior, the warning should
> be an `ExtWarn`
>  * For the cases where the code has defined behavior but changes meaning
> in a later standard, the warning should be in `-Wc*-compat`
>  * For the cases where the code becomes invalid in a later standard, the
> warning should say so
>  * We should split this warning up into enough separate diagnostics that
> we can cover all of the above cases with correct, clear, helpful diagnostics
>
> I think the different cases are:
>
>  1) C89, no suffix or L, LONG_MAX == LLONG_MAX (c99-compat), "will be
> ill-formed in C99 onwards"
>  2) C89, no suffix or L, LONG_MAX < LLONG_MAX (c99-compat), "will have
> type 'long long' in C99 onwards"
>  3) C++98, no suffix, LONG_MAX == LLONG_MAX (c++11-compat, ExtWarn), "will
> be ill-formed in C++11 onwards"
>  4) C++98, L suffix, LONG_MAX == LLONG_MAX (c++11-compat), "will be
> ill-formed in C++11 onwards"
>  5) C++98, no suffix, LONG_MAX < LLONG_MAX (c++11-compat, ExtWarn), "will
> have type 'long long' in C++11 onwards"
>  6) C++98, L suffix, LONG_MAX < LLONG_MAX (c++11-compat), "will have type
> 'long long' in C++11 onwards"
>
> 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.
>
Sounds good.


>
> 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.
>
> http://reviews.llvm.org/D9794
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150605/a308789d/attachment.html>