Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77581
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: <54220EB4.60001@sugarcrm.com>
Date: Wed, 24 Sep 2014 15:49:03 +0100
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <6A21F4EF-476E-476C-A64B-246B8929172B@ajf.me>
References: <07153B91-E12F-4B16-ADD7-86CFC75C4642@ajf.me> <54220EB4.60001@sugarcrm.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Subject: Re: [PHP-DEV] [RFC] ZPP Failure On Overflow
From: ajf@ajf.me (Andrea Faulds)


On 24 Sep 2014, at 01:22, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

> It would be nice to describe why this change is good. So far the
> motivation is "it is unintuitive" which is a fancy way of saying "I
> don't like it". Could you list which use cases this functionality
> improves, which real-life bugs it could fix, etc.?

Basically, it would mean we fail safe rather than silently mangling data =
in the unusual case where some large float is passed to a function =
expecting an integer. There are actually quite a few bugs caused by =
truncation. Among the tests I have to update, one is for a date/time bug =
caused by a floating-point timestamp being truncated on 32-bit platforms =
resulting in a completely different date. Should this RFC pass, in these =
situations you just get an error rather than having your data mangled. =
If you want it to continue mangling it, that=92s fine, (int) exists. If =
you want to handle it better, that=92s also an option.

> If this is necessary for your BigInt RFC which would not work without =
it
> for some reason (I have no idea if it is the case, but if it is) then
> please state so explicitly and describe why. That may also help to =
find
> alternatives in case somebody else sees any other solution that you =
may
> have missed.

It=92s not completely necessary, but I think bigints would make more =
sense with this RFC than without it. This RFC would make floats out of =
bounds cause an error when passed to functions expecting integers. =
Naturally, if this passes, the bigint patch would then do the same thing =
for bigints passed to functions which only support platform-native longs =
(32-bit or 64-bit). I want this to error, because otherwise bigints =
would truncate like floats, and I think that=92s likely to trip people =
up. While PHP=92s integer type would now have arbitrary precision, for =
obvious reasons most internal functions don=92t need to handle integers =
larger than 32-bit or 64-bit (e.g. for a bit mask argument, or a string =
length). I=92d much prefer if trying to do, say, str_split(=93foobar=94, =
2 ** 128); would error rather than simply truncate silently, especially =
since passing such a large value here is almost certainly an error. If =
we truncate silently, it may seem like nothing has gone wrong. After =
all, if a function runs normally, raises no errors, and does not return =
an error value, it is usually safe to assume that everything is working =
fine.

> If there are some other arguments for it, please add them to the RFC.
> Right now it looks kind of thin. I personally don't have any reason to
> assume what you are proposing is better that what we have now, and BC
> break is a cost that always must be offset by something that is worth
> more. Especially a BC break in a form of "it worked before but now it
> fails" - this can break code in so many hard to catch ways, where you
> didn't actually care at the least if the function truncates the arg
> (common situation in proxy/glue libraries, etc. - they'd be completely
> fine with garbage in - garbage out) but need special code to handle
> situations where the function fails to run altogether.

How do these libraries you speak of handle passing other types of =
arguments that fail? Surely this isn=92t a new phenomenon.

--
Andrea Faulds
http://ajf.me/