Wow, a blog post that doesn't blame me for something. That's a first. :)

He has a point about this code being used everywhere though. When we figured out what caused this we did a quick search to see how other people who use this same code deals with this issue. And for the most part they don't. The version in Spidermonkey, for example, is a newer version, but very similar. Dropping the Spidermonkey version into PHP produces the same problem. The one saving factor here is that 32-bit x87 hardware is going away pretty quickly, so this particular annoyance is getting less and less important.

This is why I love HN. Thanks for being here Rasmus, you just made it that much cooler. :)

This post is incorrect. The problem is not a bug in GCC, but rather the PHP developers making unwarranted assumptions about the hardware.

The C standard allows compilers to keep floating-point intermediate results in registers; this is both faster, and can give more accurate results. Since it is allowed, GCC does so when IEEE-extended mode is enabled by compiler flags. PHP enabled those flags, so GCC enables IEEE-extended math, and thus keeps results in registers.

There are a couple ways the PHP developers can fix this:

1. Since the code explicitly says it does not work in IEEE-extended mode, they can disable it by adding "-fexcess-precision=standard" (for GCC) or "-fp-model precise" (for ICC) to their CFLAGS.

2. Alternatively, they could compile in C99 mode; C99 changed the floating-point semantics to make IEEE mode the default.

3. They could use the system's strtod() or strtod_l() , which is presumably designed to work on the current architecture.

Finally, regarding the author's suggestion to use Clang: the only reason Clang works as he expects (eg, incorrectly) is because it apparently does not support IEEE-extended math on x87-enabled processors. Suggesting that users switch to a compiler because it is missing features is ridiculous, especially if they add support for this feature later.

The author might have something of a point in his rant that it is not exactly intuitive. When you specify 'double' you also expect computations to be done in 64 bit fp precision, so disabling the 80 bit fp flag or using SSE fp by default would have been a sane choice.

But the point remains that relying on any specific floating point semantics (in C, or any other language) is dangerous.

The potentially infinite loop in strtod was a bug, no matter how you spin it to blame the compiler. Iterative algorithms that must finish in limited time must always have a max # of iterations...

It does not seem all that unreasonable to assume (in library code for dealing with 64-bit floating point numbers) that your 64-bit floating point numbers are actually 64-bit floating point numbers.

Well this shows again that assumptions, even if they look reasonable, can be very dangerous. The C standard is vague on these things, which leaves a lot of leeway for compilers.

I like how the author rants that the existence of this bug as totally unacceptable then suggests instead using clang compiler "for those who [...] can tolerate a few bugs"

And yet from my point of view there is a world of difference between, We have bugs that cause problems that we have decided we don't care about and We have bugs we are not yet aware of, but we are responsive when you find them.

Even though I may encounter more bugs in the latter situation, I feel less pain when I encounter them. And I have the satisfaction that I'm somehow making the world a better place.

This is the first time I've heard someone argue that undocumented bugs are better than well-documented ones.

What can I say? There is a difference between errors of commission and omission. I much prefer the latter.

He also points to Compcert: a certified compiler for a subset of C. The compiler is specified, programmed and proved in Coq. It is a really impressive project: http://compcert.inria.fr/compcert-C.html

Compcert is great (it's by the same team who do OCaml). Unfortunately however it's not free software.

> forced millions of users...

While there may be millions of servers running PHP, I doubt millions of users (PHP programmers) were the ones upgrading them. I'd be shocked, if _most_ PHP programmers have ever installed PHP themselves.

I imagine most PHP programmers have at least installed a package like XAMPP on their development machine, even if they haven't compiled their own PHP binary.

Sure, if you compile it from source it's more unpleasant work, but normally I guess distributions take 'security' patches very seriously, and last time I had to install/upgrade PHP it was easy as

Installing: > apt-get install php5-xxx

Upgrading: > apt-get upgrade

Now, boohoo, that's so much work those users are forced to do...

How come I read this function out loud as String to Death?

> GNU Mono

I see Miguel finally caved!