As reported by both The Register and Zend, there's a new remote exploit bug that possibly has something to do with the way 32-bit processors handle floating point numbers.

From Zend:

Due to the way the PHP runtime handles internal conversion of floating point numbers, it is possible for a remote attacker to bring down a web application simply by adding a specific parameter to a query string in their web browser.

The bug, found here on bugs.php.net, has been reproduced on Windows and 32-bit linux systems and can cause the server hang and/or crash as a result. The real issue comes from this bug on the x87 FPU design. The bug has already been fixed in the latest SVN versions (including 5.2 that was end-of-life recently). A release to fix the issue should be coming shortly.

In a brieft post to the PHP 10.0 Blog today, Stas looks at a topic several PHPers out there have had to struggle with in their math-centric applications - how floats/doubles are handled in PHP.

Just wanted to write about the topic discussed elsewhere - how one could do money calculations with PHP? PHP has no BCD type and no arbitrary precision float type either. And for money calculations is it important to have it very precise - accountants can not allow even single penny to slip by (remember the plot of the Office Space movie?)

He basically says that the precision that PHP alone offers just isn't enough for some kinds of functionality. He also offers his own kind of solution proposal - switching the values back to (arbitrary-precision) integers and making all calculations in hundredth or thousandths of a cent.

Not that, according to Ron in the comments, there is in fact a BCMath extension already built for PHP.

In a brieft post to the PHP 10.0 Blog today, Stas looks at a topic several PHPers out there have had to struggle with in their math-centric applications - how floats/doubles are handled in PHP.

Just wanted to write about the topic discussed elsewhere - how one could do money calculations with PHP? PHP has no BCD type and no arbitrary precision float type either. And for money calculations is it important to have it very precise - accountants can not allow even single penny to slip by (remember the plot of the Office Space movie?)

He basically says that the precision that PHP alone offers just isn't enough for some kinds of functionality. He also offers his own kind of solution proposal - switching the values back to (arbitrary-precision) integers and making all calculations in hundredth or thousandths of a cent.

Not that, according to Ron in the comments, there is in fact a BCMath extension already built for PHP.

On his blog, Mike Lively has a little reminder for developers out there about working with floating point numbers in your applications, specifically their accuracy.

I know many of you all know pretty well that floating point precision and computers don't play nicely with each other. [...] I was working with a piece of code today at the office that was throwing an error saying two values weren't zeroing out when they clearly should have been.

In his code he shows the simple bit that he was using to evaluate if the result of subtraction would come to a certain value. In the comments, others share similar experiences and one even recommends another option to make things a bit more accurate - the bcmath library.

On his blog, Mike Lively has a little reminder for developers out there about working with floating point numbers in your applications, specifically their accuracy.

I know many of you all know pretty well that floating point precision and computers don't play nicely with each other. [...] I was working with a piece of code today at the office that was throwing an error saying two values weren't zeroing out when they clearly should have been.

In his code he shows the simple bit that he was using to evaluate if the result of subtraction would come to a certain value. In the comments, others share similar experiences and one even recommends another option to make things a bit more accurate - the bcmath library.