>> But please don't add another ini setting. Especially one where >> *logic* can change depending on the setting. I don't want a case >> where pow(2, 65)-1 will return different answers depending on the ini. >> That's just asking for problems. > > I edited the RFC while you were sending this for clarification. This > setting would only affect the math operators (+,/,*,-) mapping them to > their bcmath equivalents. Math functions like pow would not be > affected.
Actually, I see that as even worse. Why would 2 * 4 be possible to be different from pow(2, 3)? That doesn't really make sense (to me). I think if it was added, all of the math related extensions would need to be (should be) updated as suits. Otherwise it's just another random inconsistency... >> >> Instead, perhaps a pythonic approach may be useful (storing as >> int/float for small values, but auto-converting to arbitrary precision >> if the int/float can't exactly represent what was >> requested/computed)... Just a thought to make it useful without the >> ini complexity or performance hits. >> >> Although this will present a significant BC break (internally, zend >> engine wise), so it would probably be limited to a major release >> anyway... >> > > With a setting there would be no BC break since, if you turn it on, > presumably you want it on. Also, for scripts where the author wasn't > aware of the peril of floating point math the setting could actually > fix their existing code. When I said BC break, I'm talking about at the engine level. So all 3pd code that hooks into the engine (PECL extensions mainly) would be broken, as the structure of the ZVal would need to change to accommodate the bignum representation... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
