> 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
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
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.
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
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.
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
> 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
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.
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
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
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
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'
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
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
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
15 matches
Mail list logo