Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76922
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <alpine.DEB.2.11.1408221229360.4107@whisky.home.derickrethans.nl>
Date: Thu, 28 Aug 2014 16:44:59 +0100
Cc: Laruence <laruence@php.net>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <C0D9043A-8C43-4063-9C31-68EFDC833F05@ajf.me>
References: <88F3B0AF-786C-43BA-AD39-3D8B77D13B2F@ajf.me> <CABBJUpdZXg3Noq4UZ55d2VOkPdFKRbLPRAb2pLrLsz7iaaUogQ@mail.gmail.com> <3DEE6234-C839-4B48-A5D3-F15558CC5DFC@ajf.me> <alpine.DEB.2.11.1408221229360.4107@whisky.home.derickrethans.nl>
To: Derick Rethans <derick@php.net>
Subject: Re: [PHP-DEV] [RFC] Integer Semantics
From: ajf@ajf.me (Andrea Faulds)


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,=20
> I do think that changing it to *match* what the most used compiler =
(GCC)=20
> on our most used platform (Linux/AMD64) is what the new behaviour =
should=20
> be like =97 not something that "looks best". I think that's what =
Laruence=20
> was trying to say as well.
>=20
> It causes the least amount of BC breaks for our users.

That would also be a possibility. It=92s not my favourite behaviour, but =
it=92d at least be consistent.

However, I wonder how many applications rely on the current behaviour on =
AMD64. It=92s 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=92s 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=92t make a super-compelling case, given it doesn=92t really =
introduce any benefits (aside from the fact you can rely on $x >> $y, =
where $y >=3D 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/