Re: [RFC] ZPP Failure On Overflow

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

I think Stas's point was not that libraries don't need to think about such things *in general*, but that the checking to handle *this particular case* will not currently be in place, and might not be put in place until someone is unfortunate enough to trigger the new behaviour. 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. -- Rowan Collins [IMSoP]