

The PHP strtod() denial of service bug - mikagrml
http://blog.andreas.org/display?id=9

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

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

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

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

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

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

------
snorkel
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"

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

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

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

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

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

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

------
cosmo7
> GNU Mono

I see Miguel finally caved!

