[RFC] ZPP Failure On Overflow

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’s fine, (int) exists. If you want to handle it better, that’s 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’s 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’s likely to trip people up. While PHP’s integer type would now have arbitrary precision, for obvious reasons most internal functions don’t need to handle integers larger than 32-bit or 64-bit (e.g. for a bit mask argument, or a string length). I’d much prefer if trying to do, say, str_split(“foobar”, 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’t a new phenomenon.

--
Andrea Faulds
http://ajf.me/

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_RECOVERABLE_ERROR, you’d just get an E_WARNING.
No, you'd get E_WARNING and function would not run. Where before it
did run. That is the problem, not the warning - you add more cases where
the function does not run when it did before, and that can have profound
consequences on the code that depends on it.

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.

A function with no side effects will simply go from "garbage in, garbage
out" to "garbage in, NULL out".

I wonder how many functions actually fall into each category.

--
Rowan Collins
[IMSoP]