[cfe-commits] PATCH: Warn on left shifts which overflow, even when not due to the RHS

[Chandler Carruth]

On Mon, Feb 21, 2011 at 12:35 AM, Abramo Bagnara
<abramo.bagnara at gmail.com>wrote:

> Il 21/02/2011 05:21, Chandler Carruth ha scritto:
> > This patch (originally by Oleg Slezberg) implements a warning that would
> > have caught several major bugs we found, so I'm pretty excited about it.
> > The fundamental premise is that the user writes code as follows:
> >
> > int64_t i = 10 << 30;
> >
> > The user thinks this is a nice 10 gig constant for their disk size. The
> > compiler thinks this is -2 gigs. Oops.
> >
> > As it turns out, this is technically undefined behavior, and so it seems
> > doubly good to warn about it when we see it. The warning has a special
> > case though. It still provides a warning for the expression (1 << 31)
> > because it's undefined behavior to do this, but that warning is by
> > default ignored. If the value is converted to an unsigned integer, it
> > will have the intended value as all the bits did in fact get set. It
> > seems much less important to warn about this case. The result looks
> > something like:
>
> I don't know if this is relevant for your design, but it should be noted
> that according to C++ standard (and differently from C99 standard) the
> excess left shift of signed integers is not undefined behaviour, but it
> is implementation dependent (see C++03 5.8p2), i.e. as the shift should
> be implemented as a logical shift the result depends from integer
> representation (C++ allows 1's complement, 2's complement and signed
> magnitude).
>

Where are you seeing this? According to my copy of the C++03 standard, 5.8p2
doesn't specify any behavior for signed integers, making this most likely
undefined behavior due to omission. You might read 5p5 as being relevant,
but in that case this is actually ill formed, not just undefined behavior.

The C++0x drafts specify explicitly that this behavior is undefined for
signed integers in 5.8p2, making it my strong suspicion that it was intended
to be undefined behavior all along, and merely omitted previously. I've not
read the C standard thoroughly in this area, so I'm not commenting on its
requirements, but I'd not expect them to be different here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110221/2a14ae19/attachment.html>