Re: [PHP-DEV] [RFC] ZPP Failure On Overflow

2014-11-28 Thread Andrea Faulds
On 22 Sep 2014, at 23:42, Andrea Faulds a...@ajf.me wrote: 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. Thanks! At long last, we are at the point where I

Re: [PHP-DEV] [RFC] ZPP Failure On Overflow

2014-09-29 Thread Andrea Faulds
On 29 Sep 2014, at 02:10, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! May be this overflow checks should be optional? In old ages compilers for Wirth family languages had option to enable or disable overflow checks. If option is enabled we may throw an exception, if no - work as

Re: [PHP-DEV] [RFC] ZPP Failure On Overflow

2014-09-28 Thread Stas Malyshev
Hi! May be this overflow checks should be optional? In old ages compilers for Wirth family languages had option to enable or disable overflow checks. If option is enabled we may throw an exception, if no - work as today. Any user would be able to chose between compatibility and safety.

Re: [PHP-DEV] [RFC] ZPP Failure On Overflow

2014-09-27 Thread Andrea Faulds
On 26 Sep 2014, at 07:57, Dmitry Stogov dmi...@zend.com wrote: May be this overflow checks should be optional? In old ages compilers for Wirth family languages had option to enable or disable overflow checks. If option is enabled we may throw an exception, if no - work as today. Any user

Re: [PHP-DEV] [RFC] ZPP Failure On Overflow

2014-09-26 Thread Dmitry Stogov
May be this overflow checks should be optional? In old ages compilers for Wirth family languages had option to enable or disable overflow checks. If option is enabled we may throw an exception, if no - work as today. Any user would be able to chose between compatibility and safety. Thanks.

Re: [PHP-DEV] [RFC] ZPP Failure On Overflow

2014-09-25 Thread Rowan Collins
Andrea Faulds wrote (on 25/09/2014): No bogus value ever gets to a function - it always gets INT_MAX on overflow. If INT_MAX is harmful for this function, this change does not help as you could still pass INT_MAX and this change would not do anything. No it won't. Normally it truncates

Re: [PHP-DEV] [RFC] ZPP Failure On Overflow

2014-09-24 Thread Andrea Faulds
On 24 Sep 2014, at 01:22, Stas Malyshev smalys...@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

Re: [PHP-DEV] [RFC] ZPP Failure On Overflow

2014-09-24 Thread Rowan Collins
Andrea Faulds wrote (on 24/09/2014): 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

Re: [PHP-DEV] [RFC] ZPP Failure On Overflow

2014-09-24 Thread Andrea Faulds
On 24 Sep 2014, at 16:04, Rowan Collins rowan.coll...@gmail.com wrote: That said, most cases of garbage in, garbage out would presumably remain so, since most ZPP failures result in a return of NULL or FALSE, which would probably end up cast back to the expected type (int(0), string(''),

Re: [PHP-DEV] [RFC] ZPP Failure On Overflow

2014-09-24 Thread Stas Malyshev
Hi! That said, most cases of garbage in, garbage out would presumably remain so, since most ZPP failures result in a return of NULL or FALSE, which would probably end up cast back to the expected type (int(0), string(''), etc) by the surrounding code. Right. It’s not an

Re: [PHP-DEV] [RFC] ZPP Failure On Overflow

2014-09-24 Thread Rowan Collins
On 24/09/2014 18:40, Stas Malyshev wrote: That said, most cases of garbage in, garbage out would presumably remain so, since most ZPP failures result in a return of NULL or FALSE, which would probably end up cast back to the expected type (int(0), string(''), etc) by the surrounding code.

Re: [PHP-DEV] [RFC] ZPP Failure On Overflow

2014-09-24 Thread Stas Malyshev
Hi! So, the problem comes with built-in functions, which have some side effect, which can be usefully run with a bogus value for an integer argument. In contrast, any function which has some side effect which is actively harmful given a bogus value would be a beneficiary of the change. No

Re: [PHP-DEV] [RFC] ZPP Failure On Overflow

2014-09-24 Thread Andrea Faulds
On 25 Sep 2014, at 02:17, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! So, the problem comes with built-in functions, which have some side effect, which can be usefully run with a bogus value for an integer argument. In contrast, any function which has some side effect which is

Re: [PHP-DEV] [RFC] ZPP Failure On Overflow

2014-09-23 Thread 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

[PHP-DEV] [RFC] ZPP Failure On Overflow

2014-09-22 Thread Andrea Faulds
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. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,