Re: Zero-fill right shift.

> On 3 Feb 2015, at 14:59, Leigh <leight@gmail.com> wrote: > > On 3 February 2015 at 14:49, Andrea Faulds <ajf@ajf.me> wrote: >> It’s not “broken”, the behaviour is just different to account for it now being an >> arbitrary-precision type. >> > > That's pretty much the definition of a BC issue. Sure, it’s a BC break if you’re relying on the undefined behaviour of your platform. Which a lot of people unfortunately were doing. Actually, this specific case was already broken in PHP 7 after the Integer Semantics RFC passed, which made our bitwise shifts more consistent across platforms. >> Also, the bigint changes only affect you if you’re dealing with large integers anyway. If >> you want to preserve the horrid float promotion behaviour, you can do so explicitly. But I think in >> most cases, it’s better to trade off performance for lack of data loss. >> > > It's not anything to do with float promotion or data loss. If I'm > working with a 64-bit bitmask that gets promoted to bigint when I set > the high bit Why would it be promoted?! The high bit is the 63rd bit. It fits within a long. -- Andrea Faulds http://ajf.me/