On 22 Aug 2014, at 12:36, Derick Rethans <der...@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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
