> On 3 Feb 2015, at 14:59, Leigh <lei...@gmail.com> wrote: > > On 3 February 2015 at 14:49, Andrea Faulds <a...@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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
