Re: [RFC] Integer Semantics

On 22 Aug 2014, at 12:36, Derick Rethans <derick@php.net> wrote: > Although I think it is good to make it work the same on every platform, > I do think that changing it to *match* what the most used compiler (GCC) > on our most used platform (Linux/AMD64) is what the new behaviour should > be like — not something that "looks best". I think that's what Laruence > was trying to say as well. > > It causes the least amount of BC breaks for our users. That would also be a possibility. It’s not my favourite behaviour, but it’d at least be consistent. However, I wonder how many applications rely on the current behaviour on AMD64. It’s not terribly intuitive. For example, a shift by a negative number works like this on AMD64: $op1 << ((PHP_INT_MAX + $op2) % 64) So, for example, were I to make $op2 be -1: $op1 << ((PHP_INT_MAX + $op2) % 64) $op1 << ((PHP_INT_MAX - 1) % 64) $op1 << (9223372036854775806 % 64) $op1 << 62 Which is probably not what the user was expecting. Actually, I kinda lied, that’s just what *sane* compilers would do on AMD64. Negative bit shifts are undefined behaviour in the C standard, which gives the compiler an unlimited license to do absolutely anything it wants, including, for example, to not execute the shift altogether and assume it is dead code. In practise this is unlikely, however that is the standard. You make a good point that this is a BC break, though. This RFC in itself doesn’t make a super-compelling case, given it doesn’t really introduce any benefits (aside from the fact you can rely on $x >> $y, where $y >= 64, equalling zero). It might be better if I retracted this RFC and kept these changes to the bigint RFC. -- Andrea Faulds http://ajf.me/