Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77242
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.51 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <CA+9eiLsjR6k_j32=sXEOcd6TPg5u_nSyyDYzCSmaZXNZYexj2w@mail.gmail.com>
References: <B08F027B-EACA-42A1-BAFD-8B0FB3135016@ajf.me>
	<CAFMT4NpNqexoD+5MuVYPRCwqwgw5Ft3n2t4aXSF52_wAkuNDAw@mail.gmail.com>
	<528B8D9E-58FF-47DD-9B91-013F8844EC70@ajf.me>
	<CA+9eiLsdRRn0RxHrx=QYbJpEmp5H80hs+oB8+1MhJ0i24kDK=g@mail.gmail.com>
	<93C6A290-493F-42B3-824B-AE81ACCDBA61@ajf.me>
	<CA+9eiLsjR6k_j32=sXEOcd6TPg5u_nSyyDYzCSmaZXNZYexj2w@mail.gmail.com>
Date: Tue, 16 Sep 2014 11:19:25 +0100
Message-ID: <CAGAGxbYu6pbe1oF+iqTmZW0wQxEXbQOY5aJR0WP6SYPLxJouCw@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Andrea Faulds <ajf@ajf.me>, Levi Morrison <levim@php.net>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
From: cw@daverandom.com (Chris Wright)

On 16 September 2014 11:05, Dmitry Stogov <dmitry@zend.com> wrote:
> you already made silent break for N << 64 and N >> 64, but it may be
> explained as more consistent behaviour.
> I don't see a big difference with negative shifts.
>
> The real thing that I don't like - is a "boolean" result. Warning is not =
a
> big problem.

I'm inclined to agree with this. The warning makes sense as it's
almost certainly a userland bug, and if the expected old behaviour is
desired it can easily be modified in userland, but returning FALSE
doesn't make a huge amount of sense. This will almost certainly be
immediately cast to int(0) by the next operation - almost no-one is
going to actually check for a return value of FALSE - so it makes more
sense to just return 0 and avoid the implicit cast. This would also
produce possibly-unexpected results if a future operation was to
stringify the result, as FALSE would cast to the empty string.

I have voted in favour of the RFC as it stands as I believe that
overall the changes are positive, but ideally this particular case
would be addressed.

>
> Thanks. Dmitry.
>
>
>
> On Tue, Sep 16, 2014 at 1:23 PM, Andrea Faulds <ajf@ajf.me> wrote:
>
>>
>> On 16 Sep 2014, at 10:16, Dmitry Stogov <dmitry@zend.com> wrote:
>>
>> > Shifts by negative number may make sense. (N << -1) =3D> (N >> 1)
>> > At least receiving "false" from shift is not very pleasant.
>>
>> The problem is that changing from the current behaviour (undefined in C,
>> but typically a shift by (PHP_INT_MAX - $bits)) to do what you=E2=80=99d=
 expect
>> (shift in the opposite direction) would be a silent BC break. I think it=
=E2=80=99s
>> better to just stop it altogether and raise an E_WARNING, where it=E2=80=
=99s at
>> least obvious something went wrong, than change this behaviour silently.
>>
>> > In the patch you use SIZEOF_LONG. It probably should be changed to
>> > SIZEOF_ZEND_LONG.
>>
>> Will fix, thanks for spotting that.
>>
>> --
>> Andrea Faulds
>> http://ajf.me/
>>
>>
>>
>>
>>