<br><div class="gmail_quote">On Mon, Feb 21, 2011 at 12:41 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div><div></div><div class="h5">On Mon, Feb 21, 2011 at 12:35 AM, Abramo Bagnara <span dir="ltr"><<a href="mailto:abramo.bagnara@gmail.com" target="_blank">abramo.bagnara@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Il <a href="tel:21%2F02%2F2011%2005" target="_blank"></a><a href="tel:21%2F02%2F2011%2005" target="_blank">21/02/2011 05</a>:21, Chandler Carruth ha scritto:<br>
<div>> This patch (originally by Oleg Slezberg) implements a warning that would<br>
> have caught several major bugs we found, so I'm pretty excited about it.<br>
> The fundamental premise is that the user writes code as follows:<br>
><br>
> int64_t i = 10 << 30;<br>
><br>
> The user thinks this is a nice 10 gig constant for their disk size. The<br>
> compiler thinks this is -2 gigs. Oops.<br>
><br>
> As it turns out, this is technically undefined behavior, and so it seems<br>
> doubly good to warn about it when we see it. The warning has a special<br>
> case though. It still provides a warning for the expression (1 << 31)<br>
> because it's undefined behavior to do this, but that warning is by<br>
> default ignored. If the value is converted to an unsigned integer, it<br>
> will have the intended value as all the bits did in fact get set. It<br>
> seems much less important to warn about this case. The result looks<br>
> something like:<br>
<br>
</div>I don't know if this is relevant for your design, but it should be noted<br>
that according to C++ standard (and differently from C99 standard) the<br>
excess left shift of signed integers is not undefined behaviour, but it<br>
is implementation dependent (see C++03 5.8p2), i.e. as the shift should<br>
be implemented as a logical shift the result depends from integer<br>
representation (C++ allows 1's complement, 2's complement and signed<br>
magnitude).<br></blockquote><div><br></div></div></div><div>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.</div>

<div><br></div><div>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.</div>
</div></blockquote><div><br></div><div>Having now read the C99 standard, it has the exact same wording as C++0x drafts (I suppose that the 0x drafts are based on the C99 wording). The C89 standard is silent on the issue (likely leading to the C++03 silence). I don't think there is any inconsistency between the languages, or backwards incompatibility here. I think this restriction has merely been clarified over time.</div>
</div>