Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77560
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.83 as permitted sender)
Message-ID: <54220EB4.60001@sugarcrm.com>
Date: Tue, 23 Sep 2014 17:22:12 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>, PHP internals <internals@lists.php.net>
References: <07153B91-E12F-4B16-ADD7-86CFC75C4642@ajf.me>
In-Reply-To: <07153B91-E12F-4B16-ADD7-86CFC75C4642@ajf.me>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] ZPP Failure On Overflow
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> Good evening again,
> 
> Here’s a new RFC: https://wiki.php.net/rfc/zpp_fail_on_overflow
> 
> Thoughts appreciated, as is help with the patch, though I can probably manage on my own.

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.?

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.

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.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/