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

2014-11-28 Thread Andrea Faulds
> On 22 Sep 2014, at 23:42, Andrea Faulds 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 h

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

2014-09-29 Thread Andrea Faulds
On 29 Sep 2014, at 02:10, Stas Malyshev 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 today. >> Any user

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 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 would be able

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

2014-09-25 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. Dmitry.

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

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

2014-09-24 Thread Andrea Faulds
> On 25 Sep 2014, at 02:17, Stas Malyshev 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 >> actively harm

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.

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. Righ

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 E_RECOVE

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

2014-09-24 Thread Andrea Faulds
On 24 Sep 2014, at 16:04, Rowan Collins 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 surrou

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'

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

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

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

[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, visit