On 10/24/13, John Regehr <regehr_at_[hidden]> wrote:
> I'll be interested to see how others weigh in.

I prefer the formulation that left shift is equivalent to multiplication
by a power of two. Any overflow results in undefined behavior,
which preferably results in a diagnostic.

> If opinions remain
> divided, one way to help resolve the issue would be to stress-test a few
> large applications compiled with integer undefined behavior checking and
> then take a close look at the resulting signed left-shift UBs. If more
> of them are real bugs, you win the argument; if more of them are
> instances where people expected unsigned semantics, I win.

Not necessarily, because you are presuming that their expectation was
reasonable. If they expect unsigned semantics, they should be using
unsigned types.

> Honestly, I
> stopped looking closely at these several years ago after I realized how
> hard it was to convince people to fix the less benign integer UBs. I
> even got flamed by the main PHP guy over a signed addition overflow bug
> one time.

You will find there are many folks make little distinction between correct
code and code that has not yet failed. :-)

>
> I'm interested to hear more about situations where measurable speedup
> can be had by exploiting the remaining UBs after shift-into-sign-bit
> becomes defined. I'm afraid that I can already hear the screaming users
> when you deploy these optimizations, but at least there's a checker.
>
>> Did you distinguish between those due to shift-into-sign-bit, and those
>> which actually shifted completely off the top?
>
> We didn't make this distinction. However, according to Richard Smith,
> --std=c++11 causes Clang to turn off the shift-into-sign-bit error
> message. I hope we can tweak the -fsanitize=... flags a bit to make
> selective checking easier.
>
>> The committee has recently given serious consideration to the behavior of
>> C++ on unisys machines that are still in use... I'm not familiar with
>> them, but I hesitate to make this assumption.
>
> Well, my guess is that Unisys has already been forced to implement two's
> complement signed shifts since the alternative would almost certainly
> break shifty applications like crpyto.

What reason do you have to believe that crypto is using any signed
arithmetic? I would not.

-- 
Lawrence Crowl