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 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
