PHP Floating Point Bug Crashes Servers

angry tapir writes "A newly unearthed bug in certain versions of the PHP scripting language could crash servers when the software is given the task of converting a large floating point number, raising the possibility that the glitch could be exploited by hackers. The bug will cause the PHP processing software to enter an infinite loop when it tries to convert the series of digits "2.2250738585072011e-308" from the string format into the floating point format. The bug only seems to affect version 5.2 and 5.3 of the language." Adds reader alphadogg: "Computer scientist Rick Regan first reported the bug on Monday, and the PHP development team issued patches the following day."

Comments

1 day turn-around

[iONiUM]

The 1 day turn around for a patch is pretty impressive. I wish some bigger companies would offer such fast patches against vulnerabilities..

Re:1 day turn-around

[hazah]

There is no profit in it.

Re:1 day turn-around

[Anonymous Coward]

Two primary reasons:
1. This was a relatively trivial, extremely specific, easily reproducible bug, so fixing it was quick and low risk.
2. A major vendor like Microsoft has to do extensive testing of patches as well as give ample warning to dozens of software partners who may or may not be using some bizarre workaround for the bug or be depending on it's broken behavior. An OSS project can just put it out and let their users choose whether or not to upgrade and deal with the potential ramifications.

Note that I'm not necessarily saying one or the other is better here, it's a matter of preference and for most people it's probably situational.

Re:1 day turn-around

[Lennie]

1 day, really that long ? ;-)

I've sometimes even seen 1 hour or even minutes from certain OSS projects. I guess it was trivial to fix.

Re:1 day turn-around

[Anonymous Coward]

Or, the OSS software gives it to you for free, but 'as is'. So they can go "Here's a fix for it. If we break something else, we're not responsible. We may try to fix that, or you can go fix it yourself."

In Microsoft's case, if they break something down the line, they have potential lawsuits against them. They try to use EULA's to try and protect themselves, but it's not foolproof. They're dealing with real money, so they have people trying to mitigate further issues. And that usually means heavy testing, on a wide range of their operating system versions and a wide range of hardware configurations.

Re:1 day turn-around

[I8TheWorm]

It's because they're not spending their time improving thread-safe modules, ternary operators, flip flopping again on defaulting magic_quotes, or understanding pragmatism :)

Re:1 day turn-around

[pstorry]

Risk management.

Every change is a potential new bug. Even your security patch may bring a new security issue.

You test and you test and you test, but nothing's certain in the eyes of management. So the shipping is delayed, the testing continues, and eventually you have a batch of bugfixes and patches you're fairly certain works well together. Traditionally, you call that collection a service pack, and you ship... ;-)

(Remember the blue-screen problems a Microsoft patch caused some folks a while back? That was embarrassing. So don't kid yourself that this isn't risky.)

This is also why companies prefer to move to an established "cadence" or rhythm. Monthly security patching is Microsoft's preference, for example. IBM has some software divisions which keep to a four or six month "point release" shipping schedule. Not good enough for v9.0.2? Well, it'll probably be in v9.0.3in six month's time...

That cadence helps with testing, and reduces the risk you're taking, and therefore helps to preserve your reputation and therefore your business.

Open source projects often just ship "when it's ready", and are more open anyway. They're not thinking like a company which is trying to manage its reputation and maximise business (well, profits really).

An open source project just wants to ship something that's reliably usable and useful. That changes their motivations, and therefore changes their management of patching and shipping...

Re:1 day turn-around

[Anonymous Coward]

this is the biggest load of BS I've heard in a while... are you a Microsoft lackey or something?

If you want to talk liability: for every published bug they receive, they then _know_ about something that is broken, and (pretending for a second they couldn't use the EULA to protect themselves) they would be liable for any damages that arise from them not acting at that point. Breaking other shit by mistake with the update is not nearly as serious as not taking action against a known problem.

Stop regurgitating the corporate doublespeak... you have presented no good reason for their patches taking forever and open source patches arriving quickly. There may very well be other good reasons, but you haven't stumbled upon any by trying to sound like a middle-management know-nothing suit.

Re:1 day turn-around

[Lennie]

What you see a lot in the case of Microsoft bugs is, it usually comes from stupid design decisions in the past. Sometimes they just give up and just disable a feature completely.

It is really fun to watch. A lot of the times you can even predict them. Take for example Windows DCOM RPC, I predicted this would be a problem before Windows XP was released.

(if I remember correctly)

Microsoft releases Windows Vista "a completely new version".

They say our development model which leads to much safer code and we've checked old code as well.

Then, look at what happends, a DCOM RPC bug is found all versions of Windows from NT 4 up to Vista are vulnerable.

Nice. :-)

Re:1 day turn-around

[Anonymous Coward]

In typical PHP fashion, the patch doesn't actually fix the underlying problem, it simply checks for that one specific string. Seriously, stop gloating for 30 seconds, check the source and cringe at the incompetence.

Re:1 day turn-around

[Anonymous Coward]

Two primary reasons:
1. This was a relatively trivial, extremely specific, easily reproducible bug, so fixing it was quick and low risk.
2. A major vendor like Microsoft has to do extensive testing of patches as well as give ample warning to dozens of software partners who may or may not be using some bizarre workaround for the bug or be depending on it's broken behavior. An OSS project can just put it out and let their users choose whether or not to upgrade and deal with the potential ramifications.

Note that I'm not necessarily saying one or the other is better here, it's a matter of preference and for most people it's probably situational.

You missed a major third reason. Even if Microsoft fixes and regression-tests a bug in a day or less, they won't make it available for up to a month. This is due to their decision to go with a monthly patch cycle.

OSS projects either would not or could not embargo a security update to prevent their customers from getting it as soon as it's ready. Microsoft and many other closed source vendors like Adobe and Oracle do. Microsoft pitches this as an advantage (predictable updates!), and I laugh out loud every time I hear one of their marketing people say it.

Re:1 day turn-around

[Lennie]

"You test and you test and you test, but nothing's certain in the eyes of management. So the shipping is delayed, the testing continues"

This is how Microsoft does it:
http://www.youtube.com/watch?v=rOwMW6agpTI

That does not look like how you described it.

Re:1 day turn-around

[Lennie]

It actually starts at 5 minute, 44 seconds:

http://www.youtube.com/watch?v=rOwMW6agpTI#t=5m44s

Re:1 day turn-around

[dlgeek]

See this article for some examples about the efforts Microsoft goes through in their regression testing (especially follow through the links to Raymond Chen's blog). When Microsoft has a patch, they run it through huge server farms of boxes with hundreds of thousands of different configurations and commercial software package installed, making sure none of it breaks. Their patches include all kinds of extra workarounds to ensure software that relies on undocumented interfaces continues working.

I'm as anti-microsoft as the next guy here, but the cases really aren't comparable, and you have to give them credit for their thoroughness.

Re:1 day turn-around

[Anonymous Coward]

Are you saying that PHP doesn't suffer problems caused by stupid decisions in the past?

Re:1 day turn-around

[Shikaku]

He's not kidding nor exaggerating at all. If a security fix breaks $foo, then, only because Microsoft and $foo's company is in the USA, can be liable to be sued for it.

http://blog.seattlepi.com/microsoft/archives/109471.asp An example of a bad update breaking an MS product.

Also if it breaks the system on a laptop or desktop environment as in it won't boot, then people would be extremely mad and businesses will sue.

Re:1 day turn-around

[Lennie]

I was talking about OSS in general, PHP is not a very good example of that though. They made many mistakes in the past. :-/

Re:1 day turn-around

[0123456]

He's not kidding nor exaggerating at all. If a security fix breaks $foo, then, only because Microsoft and $foo's company is in the USA, can be liable to be sued for it.

When was the last time anyone successfully sued a software company for something like that?

Re:1 day turn-around

[tibman]

I looked. Seems they fixed it: http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_strtod.c?r1=307095&r2=307094&pathrev=307095

Re:1 day turn-around

[Anonymous Coward]

Never. But it makes for good FUD that lackeys and middle managers can tell. Most companies don't want to spend millions of dollars on a lawsuit, and Microsoft knows it, but lackeys and middle managers don't.

Re:1 day turn-around

[Anonymous Coward]

People who depend on buggy behavior deserve what they get.

Re:1 day turn-around

[Hotawa Hawk-eye]

...Breaking other shit by mistake with the update is not nearly as serious as not taking action against a known problem.

Let's say Microsoft writes a patch for an issue affecting 0.01% of its user base and deploys it immediately. The patch fixes the problem that 0.01% of the user base is having, but causes a different problem that 0.02% of its user base encounters. Is that a good thing? Sure, for those people who were affected by the first problem but not the second. Those who were affected by neither don't care. Those who were affected by both are still stuck (albeit with a different problem.) And those who were not affected by the first problem but are affected by the second just got broken.

Now those percentages may sound small, and they are. But even a small percentage of a huge number can lead to a large problem. 0.02 percent of 1 billion (a nice round number that a little Google searching for the total number of PCs in existence found) is 200,000. That means Microsoft just broke close to two hundred thousand machines, assuming all those PCs had an affected version of Windows and installed the patch. Even if you cut that by a factor of ten to account for Linux and Mac installations / people who didn't install the patch immediately / etc, that's still TWENTY THOUSAND machines. I'd call breaking tens of thousands of PCs just a wee bit serious.

Now should Microsoft fix bugs quickly? Sure, but quickly is not the same thing as immediately. They should take a _reasonable_ amount of time to reduce the chances that by fixing Peter they break Paul.

Re:1 day turn-around

[Anonymous Coward]

Except it doesn't, retard.

Re:1 day turn-around

[Anonymous Coward]

That is a ridiculous example you've provided, and it does not at all support the argument against quick turnarounds on minor bugs.

The article linked is about an attempted class action filing from 2006 regarding Micriosoft *bricking* Xbox consoles with a forced update (most likely the update was targetted at _purposefully_ bricking modded/chipped consoles). In this case, the complainants wanted Microsoft to pay for the shipping charges to get the unit restored, since (and this is key) Microsoft provides no other way to restore the unit besides sending it back to them. Btw, do you have any updates on if the class action was even allowed to go forward?

When (recently) antivirus software caused people's computers to be unbootable suddenly, there was no class action suit against Microsoft or whatever the anti-virus company was. The users just had to re-install their OS if they wanted it to be usable immediately. Tough cookies for them.

Just because people would be angry if their computer becomes unbootable after an update, doesn't mean the software provider is liable if indeed your computer doesn't boot after the update.

Also, don't forget that we're talking here about 1-day turnaround vs. (months of denial first) and then possibly up to a month after they get around to fixing it after they admit there is a problem...

Let's not forget the scope we're talking about here before pulling in all kinds of outrageous examples: the equivalent of this bug would be a floating point calculation in an ASP.net web page locking up an IIS server. If a well-funded programming team isn't able to turn around a simple patch that doesn't fucking brick your whole OS in less than a month, then the users should be angrier about the overcomplicated piece of shit bill of goods they were sold on in the first place, not the simple patch that exposed how crappy the system is.

Re:1 day turn-around

[PIBM]

This is not available in the latest PHP release either. So, for most people it will have to wait until the next release, which can be a long time. Often, you can get a specific patch from microsoft before their monthly release cycle, so I guess it's pretty much the same.

Re:1 day turn-around

[LingNoi]

Joel hasn't worked for Microsoft for more then a decade now.

Re:1 day turn-around

[hawguy]

In typical PHP fashion, the patch doesn't actually fix the underlying problem, it simply checks for that one specific string. Seriously, stop gloating for 30 seconds, check the source and cringe at the incompetence.

What are you talking about? There is more than one number that triggers the problem, and the patch does not do a simple string comparison.

http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_strtod.c?r1=304407&r2=307095&pathrev=307095

Re:1 day turn-around

[Anonymous Coward]

PHP is made of 100% pure premium stupid decision.

Re:1 day turn-around

[Goaway]

They... added a volatile?

What the hell is that function doing, if it requires that?

Re:1 day turn-around

[TheRaven64]

No, PHP has features caused by stupid decisions in the past.

Re:1 day turn-around

[dlgeek]

He was quoting Raymond Chen who is one of the key windows devs.

Re:1 day turn-around

[msobkow]

Microsoft hardware driver updates have repeatedly bricked my systems over the years. I no longer allow them to install hardware updates.

I bitched and whined about the reinstall, but I never even thought about suing anyone for it.

Maybe if I was 'merican...

Re:1 day turn-around

[hawguy]

They... added a volatile?

What the hell is that function doing, if it requires that?

Good question - I asked the same thing in a post below, but no one has answered yet.

Re:1 day turn-around

[Anonymous Coward]

This is not available in the latest PHP release either. So, for most people it will have to wait until the next release, which can be a long time. Often, you can get a specific patch from microsoft before their monthly release cycle, so I guess it's pretty much the same.

I think you're confusing unrelated issues. For PHP, those who want the patch can get it and apply it, right now. The fact that it isn't rolled into the current release doesn't matter as long as users of the current release apply the patch separately. Most systems will not be updated using the one-day turnaround patch, but will instead wait until their respective distributions update their PHP packages and send out updates. This way is slower, but easier, and will still have the patch out there in well under a month, even if it does take more than a day.

The security updates that Microsoft makes available on Patch Tuesday have never been available before the monthly release cycle. Not even once. Their non-security updates are sometimes available earlier, and they very occasionally release a security patch earlier than Patch Tuesday. But the security updates actually released on Patch Tuesday are simply not available to the public on Monday, ever. Even though, in many cases, they've been fully regression-tested for weeks.

That looks like a huge difference to me.

Re:1 day turn-around

[Patman64]

It has to do with the x87 FPU apparently. I guess the compiler is what wrecks it. All volatile means is "don't optimize this variable: we need a real reference every time from the hardware."

Re:1 day turn-around

[Goaway]

If you need to add volatiles to your code to get it to run right, then either code is doing low-level hardware accesses, is multithreaded (and some say you shouldn't be using volatile even for that), or else it is completely broken. That, or the compiler is broken.

I have a really hard time thinking up a scenario where adding a volatile like that would actually be the correct fix, and not just a change that makes the code work by random chance. It sure seems like the actual problem should be elsewhere.

Re:1 day turn-around

[Anonymous Coward]

Yeah but the vulnerability still exists in many distributions. I just checked the last Ubuntu LTS and it's still vulnerable.

Re:1 day turn-around

[antdude]

But was it tested well? Does it break anything else? :P

Re:1 day turn-around

[0123456]

I have a really hard time thinking up a scenario where adding a volatile like that would actually be the correct fix, and not just a change that makes the code work by random chance. It sure seems like the actual problem should be elsewhere.

I take it you've never had to program the x87 FPU?

I presume this is a weird consequence of the FPU hiding bits from you and using a volatile forces the compiler to pull the value out of the FPU to memory instead of leaving it in there with the extra bits of precision? If I remember correctly, it's something like 80-bits internally but 64-bits externally, so you can get different floating point results depending on the code the compiler generates..

Re:1 day turn-around

[nicolas_nch]

I prefer my security

Re:1 day turn-around

[sjames]

That's a decent enough band-aid so long as a more comprehensive fix follows. The question is will it?

Re:1 day turn-around

[MobileTatsu-NJG]

Can someone please explain to me why all these OSS projects are able to turn around security updates so fast and Microsoft cannot?

Sure:
- This isn't a security update, it's a bug fix.

- It was probably a very simple bug fix.

- No liability.

- The nature of the bug is "it's broke" as opposed to "It's behaving differently". So it's not like a million people are going to complain when their random applications lock up.

Re:1 day turn-around

[petermgreen]

On the x87 (traditional FPU for x86, still used by most code because of support for older processors) the internal temporaries are fixed size. This means if the compiler chooses to keep temporaries in FPU registers you can get marginally different results from if the compiler spills them to memory.

This has some nasty implications like doing the same comparison twice may give different results if the first comparision was done with the value still in the FPU registers and the second was done after the compiler had moved it to memory and back.

By making a variable volatile you force the compailer to store it in memory at all times and therefore ensure consistent results for comparisions involving it.

Re:1 day turn-around

[bk2204]

Actually, Microsoft's EULAs disclaim liability just like FLOSS licenses do. The difference is that Microsoft has deep pockets. Your average FLOSS project does not.

Re:1 day turn-around

[shutdown -p now]

That's precisely why pretty much all languages explicitly allow floating-point computations to be performed at precision higher than that indicated by operand types (and Java even went so far as to add "strictfp" to let you disable that behavior if desired). Reason being that your code really shouldn't care about such things. If it does, it is very likely that it is doing FP comparisons improperly in the first place. So why do they need it for a simple string-to-number conversion function?

Re:1 day turn-around

[The End Of Days]

Ah, so all we have to do is ignore the data points that contradict your prejudice and you're still right. Excellent! Did you work on the team that determined vaccines cause autism?

Re:1 day turn-around

[Gadget_Guy]

Microsoft pitches this as an advantage (predictable updates!), and I laugh out loud every time I hear one of their marketing people say it.

You might laugh out loud, but given that Microsoft has the infrastructure in place to perform the immediate release of patches, what advantage would there be for them to delay the updates other than to placate the needs of their business customers? They used to do updates as soon as they were ready, but they changed this practice based on feedback from their larger clients.

Prior "Windows Updates", people used to run systems that remained unpatched for years, so having to wait a month is still way better than it used to be.

Re:1 day turn-around

[kestasjk]

That's the first time I've heard someone complain about Zend not being pragmatic.. Usually the argument is that they're too pragmatic and need to break backwards compatibility, fix inconsistencies, and make the language less forgiving.

As someone who has used PHP quite a bit I'm curious about what you think the alternative is though:

• Is the RoR dev team really more pragmatic than Zend, and does it have better threading performance?
• Is the Perl team spending its time more effectively?
• Could a proprietary ASP.NET really fill PHP's shoes?
• Most of all: If it's so terrible (as this nightmare of a bug demonstrates) why is it in use by many of the most popular websites and web software packages?

They develop and maintain a new language, originally created by someone with no experience, for a very hostile environment, staying fairly backwards compatible while still improving the language constantly, as an independent company using an FOSS license, and ending up as one of the main web-dev languages despite lots of well-funded/well-hyped/well-established competition..
I don't think the company that pulls that off deserves so much scorn..

Re:1 day turn-around

[weicco]

Even if Microsoft fixes and regression-tests a bug in a day or less, they won't make it available for up to a month. This is due to their decision to go with a monthly patch cycle.

It wasn't Microsoft's decision. The demand came from the industry. Some people like to test the patches before committing them to production.

Re:1 day turn-around

[TheThiefMaster]

It was essentially failing a comparison of a number to itself, because one copy was in the 80-bit fpu register and the other had been truncated into a 64-bit memory location.

Re:1 day turn-around

[JoelKatz]

Believe it or not, that really does seem to be the fix for the problem. Using 'volatile' to force loads and stores to and from memory is the accepted workaround for cases where additional internal FPU precision causes a problem.

Re:1 day turn-around

[Lisandro]

Have you seen the patch?

php/php-src/trunk/Zend/zend_strtod.c

- double aadj, aadj1, adj;
+volatile double aadj, aadj1, adj;

They're declaring a couple of variables volatile so they're not optimized. In fact, you can also "patch" your Zend by compiling it with -O0.

It's a quick response, yes, but it's a hack. Someone needs to fix their FP number parser.

Re:1 day turn-around

[Goaway]

That really sounds like a questionable strategy on the part of the compiler. That doesn't seem like it should be kosher with the C spec.

Re:1 day turn-around

[Anonymous Coward]

This is an automated trolling bot written by a no life, do not reply to him.

Re:1 day turn-around

[I8TheWorm]

A couple of the tenets of pragmatic programming are making code reusable, and making it understandable. One of my issues with PHP is the naming conventions used in the myriad functions developed for it. Some are camel, some use underscores, some just use bunched up words, all for function names and for parameters.

That lack of standardization makes using PHP confusing for someone not sitting with a book next to them.

They do have some merits though. PHP is easy to get into for novice programmers, it's free for use, and because of that most inexpensive hosting plans include PHP. That's why I think it's in such wide use.

You rarely if at all find it in the enterprise. I think that's because it's difficult to maintain (I'm not going to spark a performance argument here... Smalltalk has been shown to be slower in instances and I've seen ST in the enterprise).

I likely would have praised them at the onset of my career in 1992, or when I started writing code in 1984. However, at this point I do scorn them when I know they could do better for maintainability.

Re:1 day turn-around

[MichaelKristopeit347]

ur mum's face is an automated trolling bot written by a no life, do not reply to him.

you're an ignorant hypocrite.

why do you cower? what are you afraid of?

you're completely pathetic.

Re:1 day turn-around

[kestasjk]

A couple of the tenets of pragmatic programming are making code reusable, and making it understandable. One of my issues with PHP is the naming conventions used in the myriad functions developed for it. Some are camel, some use underscores, some just use bunched up words, all for function names and for parameters.

That lack of standardization makes using PHP confusing for someone not sitting with a book next to them.

You can use the Zend framework, which builds on top of the standard library, and it is much more consistent. Also any decent IDE will have autocompletion and be able to look up the details of whatever function you need. (And I don't think any PHP functions use camel case)

I think it's not used in the enterprise mainly because most enterprises use Windows, and it's not a hand-in-glove fit when it comes to IIS. On UNIX platforms PHP use is pretty widespread.

Re:1 day turn-around

[Tablizer]

MS's "license agreement" makes them immune from just about anything short of Armageddon. And with enough lawyers, they'll probably get out of that too.

Re:1 day turn-around

[aiht]

So it's not like a million people are going to complain when their random applications lock up.

Or rather, it's not like a million people are going to complain now that their random application stops locking up because they were relying on this bug.

Hmmmm

[Anonymous Coward]

Step 1: Write stuff in PHP
Step 2: ???
Step 2.9999990834239320: Profit!

Re:Hmmmm

[drunkennewfiemidget]

I came here to make some sort of joke like that, but this one is better, so there's no point in me trying.

Re:Hmmmm

[Andrewkov]

2.2250738585072011e-308 is the combination to my luggage?

Re:Hmmmm

[Anonymous Coward]

with ants

Re:Hmmmm

[Nothing2Chere]

I read the title as

"PHB Floating Point Crashes Servers"

and was glad I don't have that PHB.

CmdrTaco was quote as saying

[Anonymous Coward]

imgladiusedperl

Re:CmdrTaco was quote as saying

[MrEricSir]

I thought people who used Perl only spoke in regular expressions?

Re:CmdrTaco was quote as saying

[localman57]

That is a regular expression. It searches for the word imgladiusedperl .

Re:CmdrTaco was quote as saying

[Anonymous Coward]

That is a regular expression. It searches for the word imgladiusedperl .

Wouldn't that be /imgladiusedperl/ ?

You remember the php bug you found yesterday ?

[unity100]

you actually havent found it ! hahaha. something like that ?

a better patch performance than this would be to actually go back in time and fix the bug before it is discovered. but then again, there would be no bug and no bugfixing would be needed. alternate timecycle breakdown ?

Re:You remember the php bug you found yesterday ?

[Algorithmnast]

Please - don't you remember the last time we did that?

Oh, I guess you wouldn't.

Re:You remember the php bug you found yesterday ?

[Tubal-Cain]

The solution is to send a bugreport back, and then send the patch to the day after that.

2.2250738585072011e-308

[Anonymous Coward]

2.2250738585072011e-308 isn't even a large number, imagine what 1 could do!

Re:2.2250738585072011e-308

[Anonymous Coward]

Just to be safe I try to keep numbers under 1.112537e-308. Anything else is way to big for practical use anyways.

Re:2.2250738585072011e-308

[VGPowerlord]

2.2250738585072011e-308 is a pretty specific number, is the bug just associated with this number or are there more potential floats out there waiting to be found?

It's one digit (the last one before the e; should be a 4 instead of a 1) from the minimum positive value for an IEEE-754 double precision floating-point number.

Re:2.2250738585072011e-308

[dumbunny]

This number is just smaller than 2^(-1022).

According to python, 2.0 ** -1022 == 2.2250738585072014e-308. You can check that last significant digit in the mantissa using integer math in python:

>>> x = 22250738585072011
>>> y = 22250738585072014
>>> for num in xrange(1022): x *= 2; y *= 2 ...
>>> print str(x)[:20], '...', str(x)[-20:]
99999999999999987277 ... 51323238920926265344
>>> print str(y)[:20], '...', str(y)[-20:]
10000000000000000075 ... 77840486139094368256

The number in question is just beyond the range that fp is intended enough to handle, but probably not far enough for some initial validation logic to catch. It is probably not too difficult for the bug fixers to verify that the range issues are handled properly now that they know about it.

Re:2.2250738585072011e-308

[enec]

1.112537e-308 ought to be enough for anybody.

That's actually a small number, a lot less than 1.

[Anonymous Coward]

Way less than 1.

Why does this code even exist?

[TheRaven64]

Maybe I'm missing something, but why does PHP have its own version of strtod()? It's a standard C99 function, so you'll find it in libc or equivalent in any C99-compliant platform (including Windows) and more effort has probably gone into optimising that version than the PHP version, although if you're converting from strings to floating point values anywhere performance critical then you're probably Doing It Wrong.

Did the Zend team think that there weren't enough security holes in PHP and decide to increase the attack surface?

Re:Why does this code even exist?

[Anonymous Coward]

Did the Zend team think that there weren't enough security holes in PHP and decide to increase the attack surface?

I thought that was the rational for all of PHP.

Re:Why does this code even exist?

[EkriirkE]

There are several bugs in their conversion functions (data integrity)- apparently they don't bother fixing them unless it does something like take down a server.

Re:Why does this code even exist?

[flyingfsck]

Yes, but C wasn't invented here....

Re:Why does this code even exist?

[fishbowl]

>Maybe I'm missing something, but why does PHP have its own version of strtod()?

That's a very good question. PHP's strtod is quite complicated, has its own memory allocator, does its own localization and rounding, and it is going to some lengths to ensure its own thread safety. If I were to guess, my guess would be that some of the target platforms for PHP/Zend are deficient in these areas.

Re:Why does this code even exist?

[Malard]

Given that it only affects 5.2 and 5.3, (and without reviewing the codebase) maybe they did move to strtod() since.

Re:Why does this code even exist?

[Yetihehe]

if you're using PHP anywhere performance critical then you're probably Doing It Wrong.

FTFY. (disclaimer: I'm programming in php daily and I like it).

Re:Why does this code even exist?

[Anthracks]

Except 5.3 is the latest version, so that doesn't make sense.

Re:Why does this code even exist?

[Wrath0fb0b]

Maybe I'm missing something, but why does PHP have its own version of strtod()? It's a standard C99 function, so you'll find it in libc or equivalent in any C99-compliant platform (including Windows) and more effort has probably gone into optimising that version than the PHP version

Sometimes the overhead required to take values between languages actually makes doing it in the lower performance language slower, even if it's more highly optimized. This obviously manifests itself much more readily in quicker functions like strtod() where the overhead is likely to be large relative to the actual execution time. .

Just for a taste, in Python (I'm no php expert) in order to call a C function you must context switch (flush registers), unbox the value into the native type, perform the operation, rebox the value into the Python type, then context switch back to the interpreter. Here's the strdod() example in python (I think) with the error handling

int
Py_strtod(PyObject const *string, PyObject *target)
{
        target = 0;
        if ( !PyString_check(string) )
                return -1; /* Should we set something so the caller knows why this failed? */
        const char* const cstr = PyString_AsString(string);
        const double cdoub = strtod(cstr,NULL);
        if ( 0 != errno ) /* something something */
        target = PyFloat_FromDouble(cdoub);
        if ( PyError_Occured() ) /* something something */

        return 0; // Success
}

So in the process of using the faster C function, we've changed context a twice and had to check for a number of errors that are impossible to throw otherwise. Is it worth it for strtod()? Maybe, but not surely.

Re:Why does this code even exist?

[TheRaven64]

Localization I can almost understand. OS X is the only platform I know of that lets you specify a per-thread locale that functions like this respect. But memory allocator? It's converting a string to a double - it shouldn't need a memory allocator at all, it just scans a string and collects the digits into a mantissa and exponent then. And thread safety? It's a pure function! It doesn't need any thread safety!

Re:Why does this code even exist?

[Anonymous Coward]

if you're using PHP anywhere then you're probably Doing It Wrong.

FTFY. (disclaimer: I'm programming in php daily and I like it).

(I program in PHP daily, and it's second only to MySQL in causing me grief.)

Re:Why does this code even exist?

[BradleyUffner]

Localization I can almost understand. OS X is the only platform I know of that lets you specify a per-thread locale that functions like this respect. But memory allocator? It's converting a string to a double - it shouldn't need a memory allocator at all, it just scans a string and collects the digits into a mantissa and exponent then. And thread safety? It's a pure function! It doesn't need any thread safety!

each thread in windows has its own independent localization settings also.

Re:Why does this code even exist?

[localman57]

I don't think you understand how floats work. You don't "just collect them". You have to convert them into a fraction represented as a power of two. The exponent is a power of two, not a power of 10. The mantissa is the numerator of that fraction, typically with the leading 1 removed. Granted, this is something that could occur on the stack.

As for thread safety, there's a lot of math that has to happen to cacluate that fraction. On many systems, particularly embedded systems on micros without a float unit, static locations are allocated for this temporary memory, because stack accesses are often very slow on low end micros without good indexed-address instruction sets. Therefore, it is expected that the floating point libraries are not to be used reentrantly. If you launch multiple threads (or do floats at different interrupt levels) you have to save the float library static space as part of your context.

Re:Why does this code even exist?

[localman57]

An interesting side effect of this, by the way, is that the number 0.1 cannot be exactly represented as an IEEE floating point number.

Re:Why does this code even exist?

[wmbetts]

Sounds like you need to learn how to use the language a little bit better.

Re:Why does this code even exist?

[Anonymous Coward]

you are new in php, right ?

Re:Why does this code even exist?

[dkf]

Maybe I'm missing something, but why does PHP have its own version of strtod()? It's a standard C99 function, so you'll find it in libc or equivalent in any C99-compliant platform (including Windows) and more effort has probably gone into optimising that version than the PHP version, although if you're converting from strings to floating point values anywhere performance critical then you're probably Doing It Wrong.

A number of languages have their own versions of strtod(), and it's because the system version is often deeply sub-optimal. (Going the other direction is even worse, especially if you want minimal representations of numbers.) Typically, system library authors stop once they've got something that works well enough, whereas other clients of that sort of functionality are much more exposed to it and so care much more about it being optimal. (After all, system library authors tend to think that people don't convert back and forth a lot. Mostly they don't, but since when did that cover 100% of cases?)

Which isn't to say that if you're is reimplementing a system library function, you can get out of testing it very thoroughly. Oh no, not at all...

Re:Why does this code even exist?

[shutdown -p now]

The thing with PHP is that you rather have to learn how not to use it to be better with it - there's so many minefields there.

Re:Why does this code even exist?

[Obfuscant]

A number of languages have their own versions of strtod(), and it's because the system version is often deeply sub-optimal. (Going the other direction is even worse, especially if you want minimal representations of numbers.) Typically, system library authors stop once they've got something that works well enough, whereas other clients of that sort of functionality are much more exposed to it and so care much more about it being optimal.

Yes, because PHP is so widely known as a hard-number-crunching programming language that the time it takes to convert a string to binary double is criti-fucking-al. And it is well known that there are no standard, optimized math libraries that can do that job.

I mean, all of the bigger climate simulation models are written in PHP, don't you know? FORTRAN is just too damn slow for such things.

As for the previous poster who complained about how hard it is to make C calls from Python (as an example of how hard it is for PHP to do the same), well, yes, if you had to make your own call to the C function strtod you might have a point. But that call would be buried internal to the PHP system and wrapped by a PHP function so the programmer wouldn't have to do the hard work, and it would be done at the internals level.

Which isn't to say that if you're is reimplementing a system library function, you can get out of testing it very thoroughly. Oh no, not at all...

But it is to say that if you are reimplementing the C library in PHP you are doing something very very wrong and very very stupid.

Re:Why does this code even exist?

[kestasjk]

It's because they're stupid, that's why.. That's why everyone does everything..

Re:Why does this code even exist?

[DavidTC]

I don't think you understood the question. The question is why PHP build its own implementation of a rather low-level library function that's actually part of the C99 standard. (And I'm pretty sure PHP requires C99 to compile.)

No one's saying people who program in PHP should do anything different. They're saying that PHP itself should do things using standard libraries.

One of the reason standard libraries exist is to get bugs like this being centralized to one location, so they're only fixed once ever.

Re:Why does this code even exist?

[Firehed]

Just like any language or tool that's easy to learn. See also: Ruby on Rails.

Re:Why does this code even exist?

[shutdown -p now]

Last I checked Ruby didn't have abominations such as implicit conversion of stings to numbers in operator ==.

Yes, every language and framework have some nasty bits, but some have more than others, and PHP is on the "oh fuck!" end of that spectrum.

Re:Why does this code even exist?

[Anonymous Coward]

I looked at zend_strtod() in zend_strtod.c (http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_strtod.c?view=co&content-type=text%2Fplain) and it just blew my head off. I don't undertand their rational for using such a convoluted and home grown version when in the end it simply returns a machine double anyway. I can understand, to some extent, if zend_strtod() is returning a value that strtod() can't handle.

I tried these exact same values in C program on a ten year old IBM Thinkpad running Slackware 12.0 and it only had a minor problem, the last digit was 2 instead of 1.

I also don't understant why they have their own BigInt and all. They could have used, GNU multi-precision arithmetic library and be done with it.

Re:Why does this code even exist?

[tokul]

If I were to guess, my guess would be that some of the target platforms for PHP/Zend are deficient in these areas.

Deficiency never stopped PHP from using native strcasecmp() and repeatedly fsking up

Re:Why does this code even exist?

[EETech1]

That is a concern with single precision floating point numbers, but doubles will have no problem exactly representing any number out to 10 decimal places or more depending on the size of the number. Singles can be in the range of 2^-31 to 2^31, and being that this number is much larger, Im assuming it is double precision, which is an IEEE format, and does not have that limitation.

Re:Why does this code even exist?

[Anonymuous Coward]

in Python (I'm no php expert) in order to call a C function you must context switch (flush registers), unbox the value into the native type, perform the operation, rebox the value into the Python type, then context switch back to the interpreter.

At no point there happens any context switch. I think you're terribly confused about terms like 'native code' and 'interpreter' mean.

As to the boxing/unboxing of the arguments, it's pretty cheap; that's certainly not the reason why these dynamic languages are so slow.

Re:Why does this code even exist?

[Anonymous Coward]

You seem to have converted a string into two strings...

Re:Why does this code even exist?

[amoe]

FYI, the grandparent's meaning for 'optimal' was ambiguous, it didn't necessarily refer to efficiency. Could also be referring to bugs in the system strtod(). OTOH I agree that efficiency is the more likely interpretation, just about.

Re:Why does this code even exist?

[aiht]

You're missing his point.
A double stores more precision, sure, but that does not mean that it can store a recurring-binary-digit fraction.
It's the same as how you cannot accurately represent the fraction 1/3 in any finite number of decimal digits after the decimal point.

DoS also needed

[ickleberry]

Yes each time someone access it will start an infinite loop, but each PHP page has a max. processing time (usually set to around 30 seconds). So still quite a number of requests to the offending page are needed to bring the server down.

To try the bug for yourself: $a = (float) "2.2250738585072011e-308";

Re:DoS also needed

[domatavus]

Fixed on monday? I'm running "PHP 5.3.4-pl0-gentoo (cli) (built: Jan 1 2011 15:31:19)" in an interactive shell, but I can't seem to trigger the bug...

Re:DoS also needed

[Nixoloco]

Did you try on a 64bit system? The summary wasn't clear, but this should only affect 32bit, x86 systems.

Re:DoS also needed

[JoelKatz]

The max processing time check won't help you. It doesn't occur inside internal library functions. It is only checked between them.

Re:DoS also needed

[ickleberry]

It does help me. After 30 seconds it gives up.

This bug is a bit of a non-issue. I think there are very few PHP scripts that take such a high value for input from an ordinary user in string format and if you want to bring down a web host there are plenty of other ways to make an infinite loop.

Re:DoS also needed

[JoelKatz]

Oops, or may be it will. It depends exactly which check we're talking about.

Floating point bugs

[hhedeshian]

Sweet. PHP finally has the qualifications to enter the X86 CPU market.

2.2250738585072011e-308

[Javajunk]

2.2250738585072011e-308 is a pretty specific number, is the bug just associated with this number or are there more potential floats out there waiting to be found?

Even I could patch this...

[Anonymous Coward]

if ($input == "2.2250738585072011e-308") { return 2.2250738585072011e-308;}

Re:Even I could patch this...

[Anonymous Coward]

Why just that one value?

They should have a table that maps the appropriate string to each possible float value.

Infinite loop seems appropriate

[gstrickler]

I mean, for all practical purposes, it's an infinitely small number, so why shouldn't it be an infinite loop?

Very large?

[GrAfFiT]

Am I the only one to notice that 2.2250738585072011e-308 is not very large?
Apparently, some journalists need a patch too.

My 2.2250738585072011e-308 cents.

Re:Very large?

[Chapter80]

Am I the only one to notice that 2.2250738585072011e-308 is not very large?

It depends on what font you display it in.

It is a string, after all.

Re:Very large?

[gmuslera]

At least in spanish, a possible translation of large, that also is almost letter by letter the original word, is "largo", that in fact is more about lenght than size. And that number with all the digits qualify as a very long string. Maybe the original joiurnalist wrote that in spanish, or have spanish as mother tonge (ok, or maybe another latin derived language where that happens).

arg

[Anonymous Coward]

Anyone found the equivalent of this and then felt the need to beat someone to death?

floor ( some_$_amount * some_factor + 0.5 )

Hey! That's the combination to my luggage!

[damn_registrars]

I guess I'll have to keep the copy of the combo somewhere other than on my PHP server now...

Wow, that's an extremely LARGE number you've got!

[Anonymous Coward]

Tired of being "normal"? Our brand of V146R4 can give you a subnormally large PEN15! Order NOW!

Birds

[SnarfQuest]

Are blackbird OS's written in PHP? Also fishes?

Nope not just you.

[ericvids]

And yep TFA did qualify it as the largest subnormal double-precision number. Of course the journalist probably didn't know what that meant.

*Now* can we admit PHP sucks?

[MostAwesomeDude]

The inconsistent type system, lack of Unicode support, lack of namespaces, quirky parser, and other stupidities (== vs. ===) weren't enough, so. Is this bug inane enough to actually get people to realize that PHP bites?

Re:*Now* can we admit PHP sucks?

[LingNoi]

PHP has namespaces.

Re:*Now* can we admit PHP sucks?

[Leolo]

Everybody inteligent already knows that PHP bites. That doesn't prevent it from being widely used.

Re:*Now* can we admit PHP sucks?

[MichaelKristopeit332]

i've been saying this about intel chips for DECADES... why won't anyone listen? INTEL CHIPS SUCK! they once handled a single floating point edge case incorrectly! AND THEN THEY FIXED IT! WHY WOULD ANYONE USE AN INTEL CHIP?

ignorant hypocritical marketeering = the highest level of insight.

slashdot = stagnated.

Re:*Now* can we admit PHP sucks?

[wmbetts]

I wish I could mod you up. Pretty much everything the OP complained about has been addressed.

Re:*Now* can we admit PHP sucks?

[Anonymous Coward]

PHP also has unicode support

Re:*Now* can we admit PHP sucks?

[Bigbutt]

Alternate suggestions? Just curious as I do some PHP scripting for various things.

[John]

Re:*Now* can we admit PHP sucks?

[rev0lt]

Funny how so many languages don't have unicode support, namespaces, have sometimes a quirky browser, ambiguous commands and people aren't claiming it sucks. Perhaps the best example is the C language - you probably used more code written in C to post your disliking of php than you will ever program in any language during your lifetime.

Re:*Now* can we admit PHP sucks?

[wmbetts]

The OP is full of shit. It does have unicode support and does support namespaces. The generalization of the parser I have no idea what he's talking about and == vs. === makes sense if you know what you're comparing.

Re:*Now* can we admit PHP sucks?

[rev0lt]

s/browser/parser

Re:*Now* can we admit PHP sucks?

[jjohnson]

The only reason to use PHP is if you're scripting in a shared hosting environment where PHP or Perl CGI scripts are the only options available.

If you're not, you should look at either Python or Ruby. Either will be vastly better, along with some less popular choices like Lua, Groovy, Scala, Erlang...

Basically, anything else. It's not that PHP can't be sufficient, it's that it has a long and hideously compromised development history and actually demands far more of you, the scripter, to make it safe and useful, than does any of the other scripting languages.

Re:*Now* can we admit PHP sucks?

[Anonymous Coward]

OP believes PHP doesn't suit his needs, for whatever the reason, and OP must preach the "suckage of PHP" to the rest of the Internet. OP can suck it.

Re:*Now* can we admit PHP sucks?

[Ant P.]

PHP Warning: assert(): Assertion "strlen("£") == 1" failed in /home/ant/nou.php on line 3

Awesome Unicode support there, buddy. Performance of C combined with the user-friendliness of an interpreted high-level language! Oh wait.

Who's full of shit again?

Re:*Now* can we admit PHP sucks?

[wmbetts]

PHP Warning: assert(): Assertion "strlen("£") == 1" failed in /home/ant/nou.php on line 3

Awesome Unicode support there, buddy. Performance of C combined with the user-friendliness of an interpreted high-level language! Oh wait.

Who's full of shit again?

Awesome incorrect use of a language while trying to sound smart. If you don't even know how to use a language please refrain from commenting on perceived deficiencies.

?php
mb_internal_encoding('UTF-8');
if (mb_strlen("£") == 1) {
                print "lol@op being full of shit\n";
}

Re:*Now* can we admit PHP sucks?

[Anonymous Coward]

Apparently you. The function you should have used was mb_strlen().

Re:*Now* can we admit PHP sucks?

[Just Some Guy]

PHP has namespaces.

syntax\\choices\\stupid->agree();

Re:*Now* can we admit PHP sucks?

[Anonymous Coward]

Cool! You have to use a completely separate set of functions if your string might be unicode. You showed him!

Re:*Now* can we admit PHP sucks?

[Ant P.]

"Correct" use of the language is to ignore string functions entirely and use an optional extension, because they don't actually support Unicode. In 2011. Amazing.

You know, C actually has a valid excuse for that sort of thing. But I'm sure you'd rather call people names all day like a retarded skript kiddie, than admit PHP's Unicode handling is ass-backwards and crippled compared to everything else out there.

Re:*Now* can we admit PHP sucks?

[Anonymous Coward]

Try using mb_strlen(), numbnuts.

Re:*Now* can we admit PHP sucks?

[MostAwesomeDude]

Python 2 has Unicode string literals...

$ python
Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> if len(u"£") == 1: ... print "Lawl @ some kid thinking PHP's a real language" ...
Lawl @ some kid thinking PHP's a real language

And of course, Python 3's strings *default* to Unicode...

$ python3
Python 3.1.2 (release31-maint, Sep 17 2010, 20:27:33)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> if len("£") == 1: ... print("Wait, Unicode by default? Awesome!") ...
Wait, Unicode by default? Awesome!

So I think you need to go stuff it.

Re:*Now* can we admit PHP sucks?

[Anonymous Coward]

AFAIK the reason the standard string functions have not been upgraded to handle unicode is partly down to legacy support and partly due to the fact that the unicode implementation is much slower. Having unicode specific functions gives the developer the choice.

PHP has its quirks (largely due to the fact it started life when the internet was a very different place) and you have to know what you are doing to get the most out of it. However, once you've mastered it, it is a fantastically powerful and flexible scripting language.

Re:*Now* can we admit PHP sucks?

[Anonymous Coward]

In light of its excellent design, extreme maturity, and CPAN I think you have to be a little crazy, or for some financial reason hell-bent on reinventing the wheel, to program the web in anything other than mod_perl.

Re:*Now* can we admit PHP sucks?

[jjohnson]

The "excellent design" of Perl?

Good one, AST.

Re:*Now* can we admit PHP sucks?

[Anonymous Coward]

Say what you like, but learning PHP has enabled me to make a lot of money. I'm self-employed, I've written a variety of useful applications that I offer on various web sites, and I make my house payment every month (and more!) with the results of what I've coded in PHP. All by myself in my tiny little office.

So feel free to bash PHP all you like, it's not going to make me suddenly jump up and scream, "ZOMG, I have to dump PHP and learn JAVA or Python or Ruby RIGHT THIS SECOND!!!"

Is PHP perfect? Far from it. (Even I get cranky because 'needle' and 'haystack' aren't consistent.)
Does it work well enough to let me earn a pretty damn good living? Yes, it does.

Re:*Now* can we admit PHP sucks?

[sootman]

> *Now* can we admit PHP... ... is perfectly suitable for literally thousands upon thousands of tasks?

In other news, Euclidian geometry cannot correctly describe Mercury's orbit. Therefore the value of everything ever done with this type of math, from the pyramids to Apollo 11, is negated.

THERE IS NO PERFECT LANGUAGE. PHP is 100% good enough for absolutely everything I do day to day, and has been a paying gig for nearly a decade. My job does not require me to perform calculations on very large numbers. If PHP becomes unable to pull names and phone numbers from a database, THEN I'l consider using something else.

PS: did you miss the part of the summary where it said this was patched in a day? Please share with us the name of your bug-free language of choice.

Re:*Now* can we admit PHP sucks?

[spitzak]

If you think strlen should return the number of "characters" in Unicode then you are the one that is full of shit.

I assume this is returning the length of the UTF-8 encoding, which is an actually useful value.

Only beginner programmers think "characters" are important. Eventually they will learn, but only after making boneheaded screwups like you just did. Your sort of thinking is why I18N is not working after 20 years of trying.

Re:*Now* can we admit PHP sucks?

[kronosopher]

PHP has namespaces.

syntax\\choices\\stupid->agree();

First of all, none of that is in any way valid PHP. Secondly, arguing over syntax is largely irrelevant. Syntax is often drastically different between languages and good programmers don't notice because it doesn't substantially assist or impede the process of actual programming. Assess overall accessibility, usability and capability before even paying any attention to syntax.

The inconsistent type system, lack of Unicode support, lack of namespaces, quirky parser, and other stupidities (== vs. ===) weren't enough

All of your points are well received. As a PHP developer for 10 years, I can safely say that it's caveats are well known to me. The fact is that it's an easy target because it's so large. People wouldn't bother to troll if it weren't so popular. And it's popularity is easily attributed to it's many qualities, despite numerous and often glaring issues. The same thing manifests in any project of significant scope and size - no one is perfect.

Re:*Now* can we admit PHP sucks?

[tokul]

PHP has namespaces

Only if you limit your code to newer PHP versions.

Re:*Now* can we admit PHP sucks?

[LingNoi]

namespaces was added in 5.3.

If you're using less then 5.3 then you're using a php version that is no longer being supported (with the exception of the emergency fix for this bug).

Re:*Now* can we admit PHP sucks?

[makomk]

C was designed as a high-level replacement for assembler. It can get away with these things. PHP, on the other hand, is supposed to be an easy language for writing web applications in and therefore can't.

Re:*Now* can we admit PHP sucks?

[m50d]

I could make that statement about any language in existence. Sure, PHP is good enough to make money in. But there are better alternatives for pretty much all use cases. And if you look at the numbers, you'll find more people making more money in each of Java, Python and probably even Ruby.

Re:*Now* can we admit PHP sucks?

[m50d]

Funny how so many languages don't have unicode support, namespaces, have sometimes a quirky browser, ambiguous commands and people aren't claiming it sucks. Perhaps the best example is the C language - you probably used more code written in C to post your disliking of php than you will ever program in any language during your lifetime.

C sucks enormously a general-purpose language. If you're writing new programs in C outside a very limited set of circumstances (i.e. where you need the performance or precise control of the machine), you're doing it wrong. However, C is not a general-purpose programming language; it's a systems programming language, and useful within that domain. I think you'll find that any remotely popular general-purpose programming language that sucks as much as PHP will have people telling you about it.

Re:*Now* can we admit PHP sucks?

[CodeShark]

Sorry, can't agree with the conclusion that it "demands far more of the scripter to make it safe and useful".

What it requires is the discipline to learn how to use the whole stack and set of library routines properly and reduntantly, that is, to get in the habits of using the modules that put out properly developed and sanitized x/html or HTML5 front end code that is jquery / json / ajax 'ified and validated connecting to pages that then also properly sanitize the incoming "post" variables -- is an extremely HARD to hack combination -- and every last bit of the code at all levels between my script and the real world has had literally thousands of eyes looking for security holes to plug. . All I have to do is use those libraries correctly over, and over, and over again until I am faster at coding things right than I am at having to track and fix bugs later because not enough eyes have looked through the os/server/database code.

Thing is, just by using those libraries at a host provider who is up to the task of patch testing and implementing the big fixes for linux/apache/php/mysql, I don't have to worry about it

Re:*Now* can we admit PHP sucks?

[rev0lt]

C is by definition a general purpose programming language but PHP is not. If calling C a systems programming language makes you happy, go ahead - BASIC and JAVA are also system programming languages in some architectures. PHP is closer to a DSL than to general purpose language.
And yes, PHP does suck, but not by not having some buzzword funcionality you think is important.

Re:*Now* can we admit PHP sucks?

[tokul]

If you're using less then 5.3 then you're using a php version that is no longer being supported (with the exception of the emergency fix for this bug).

Version I am using works. I don't see point for upgrading to newer versions.

I don't write code which limits interpreter choice only to newest version (it would limit my user base) and I despise coders who put unneeded language constructs that break older versions. It looks funny when person maintains two library versions and the only differences between them are bugs fixed in PHP5 library version and language constructs from PHP5.

Re:*Now* can we admit PHP sucks?

[Anonymous Coward]

> The "excellent design" of Perl?

Perl's adherence to natural language principles contributes a great deal to its excellence:

http://www.wall.org/~larry/natural.html

Re:*Now* can we admit PHP sucks?

[Anonymuous Coward]

For anyone who had to suffer through Perl's unicode support, having a separate set of functions for multibyte IS the right, sane approach.

In Perl, some strings are surreptitiously tagged as utf-8 and some not, based on runtime switches, locale environment settings, and the phase of the moon. You could never be sure if length($s) will return you the length in 'characters' or the length in bytes. Even if you turn utf-8 on overall, you still have to flag file names as utf-8 by hand, one by one, to prevent perl from making a mess out of them.

'Transparent' support of unicode is a stupid, broken idea, and nobody with a bit of clue will still be advocating it.

Re:*Now* can we admit PHP sucks?

[Anonymous Coward]

The generalization of the parser I have no idea what he's talking about

I don't know if this is what the OP was referring to, but

new Foo()->monkey();

Re:*Now* can we admit PHP sucks?

[LingNoi]

It's not about using the latest and greatest. PHP 5.2 support was stopped in mid December.

It's like complaining about bugs in windows 95.

Sure it might work for you but you can get off your high horse about using it.

Re:*Now* can we admit PHP sucks?

[Ant P.]

Only beginner programmers think "characters" are important.

Tell that to the PostgreSQL developers. I'm sure they'll be falling over themselves to redefine every single string function in terms of bytes.

Your sort of thinking is why I18N is not working after 20 years of trying.

Maybe you should try harder.

~ $ perl6
> '£'.chars
1
> '£'.bytes
2
> '£'.encode.contents
194 163
> '£'.encode('iso-8859-1').contents
163

Re:*Now* can we admit PHP sucks?

[spitzak]

perl -e "print length('£')"
2

My submission mention the cause of the problem

[yuhong]

http://slashdot.org/submission/1435314/DoS-attack-found-in-PHP-thanks-to-x87-FP

Re:My submission mention the cause of the problem

[JoelKatz]

It's not fair to blame this on the x87 FP. The bug is in PHP.

PHP performs operations and gets results that the compiler ensures fully comply with the requirements of the C standard. PHP relies on assumptions that are false for the x87 FP, but these are *invalid* assumptions.

Primary blame goes to PHP.
Secondary blame goes to the C specification for not putting tighter requirements on floating point operations.
Tertiary blame goes to x87 FP for providing a more accurate answer than PHP expected.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Who uses floating point input in PHP?

[FunkyELF]

Just curious?
I'm wondering what kind of PHP software would use floating point as an input.
I'm trying to think of all the PHP stuff I run at home and at work and can't think of a single instance. (MediaWiki, Ampache, Gallery, Bugzilla).

Re:Who uses floating point input in PHP?

[wmbetts]

Anything that deals with shipping with USPS apis would. I've seen people get hung up on why some value (i forget example what now) was being returned incorrectly. Turns out they had to cast the value to a float before passing it to the api.

Re:Who uses floating point input in PHP?

[Obfuscant]

Anything that deals with shipping with USPS apis would.

Any USPS inteface that deals with numbers like 2e-308 is, well, fascinating to think about but hardly relevant to the real world.

I mean, "I'd like a penny stamp please". "Here are 5e307 2e-308 cent stamps instead...."

Re:Who uses floating point input in PHP?

[Firehed]

You probably wouldn't do it directly, but as soon as you do any math on the value it will get cast to a float (or int, depending on the values). I'd bet a lot of database abstraction layers will do just such a thing, among plenty of other tools.

$ php -a
Interactive shell

php > var_dump('1.1');
string(3) "1.1"
php > var_dump('1.1' + 0);
float(1.1)

how does the patch work?

[hawguy]

I don't understand why the patch solves the problem....though I haven't done any serious software development for years. It looks like all they did was add the "volatile" keyword to a variable declaration.

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/Zend/zend_strtod.c?r1=307095&r2=307094&pathrev=307095

From:

double aadj, aadj1, adj;

To:

volatile double aadj, aadj1, adj;

But after quickly reviewing the code, I don't see why the volatile keyword fixes this problem. It doesn't appear to be multithreaded code where another thread could stomp on the variable, and it just seems to be straight arithmetic, it doesn't seem like they are handing it off to a math coprocessor and then later waiting for the variable to be set.

Does the volatile keyword change the compiler optimizations in a way that avoids the problem?

Re:how does the patch work?

[jspenguin1]

The x87 registers are all 80 bits long, while standard doubles are only 64 bits. You can get into a situation where two floating point registers contain different values that round to the same double value, yet they don't compare equal. Adding the volatile keyword forces the compiler to copy the registers to the stack and read them back every time they are accessed, truncating them to 64 bits. The patch is only needed on x86 because x86_64 uses SSE3 for floating point, which works with 64-bit floats natively.

Re:how does the patch work?

[adamofgreyskull]

There's a link from Rasmus' tweet to a GCC "bug" that explains the problem and potential fixes, one of which is:

(2) A partial but simple solution: Do comparisons on volatile variables only.

Hope this has been enlightening!

Re:how does the patch work?

[19thNervousBreakdown]

I'm too lazy to actually figure out exactly what's happening, but that's most likely correct. The volatile keyword prevents the compiler from doing things like moving values into registers, and the patch mentions that it is a problem with the FPU. I'm guessing that there's some sort of approximation algorithm happening, which stops when the error is sufficiently low. If that value got moved to something with different precision, it could stop converging.

C purists will say that you can look at code and tell exactly what assembler output it will result in, but that's a ridiculous claim on any sort of optimizing compiler--a whole lot of stuff you didn't specify goes on.

Re:how does the patch work?

[hawguy]

Sounds like a very reasonable explanation and makes sense. But....shouldn't the compiler already know this and pull the variable out of the 80 bit FPU register into a 64 bit double before doing an == comparison between doubles? Seems like this problem would nearly always be the case when doing floating point equality comparisons.

Re:how does the patch work?

[shutdown -p now]

You can get into a situation where two floating point registers contain different values that round to the same double value, yet they don't compare equal

Pretty much every FAQ on the use of floating point types in programming has "do not ever compare two floating point values for equality" in the first 3 items. Why the hell do they need a comparison like that there?

Re:how does the patch work?

[Obfuscant]

But....shouldn't the compiler already know this ...

If you are using memory-mapped IO, the compiler won't know if you are reading from an external device like an FPU or a simple memory location.

This kind of coding is standard for IO libraries. Things like reading values from memory mapped UART registers. A smart compiler will optimize the actual memory access away and rely on the previous read that is has stored in a local register. Without calling the address volatile you can wait all day for the IORDY bit to go high on a serial input device, as the CPU simply bit-compares the data in an internal register.

This is why you use the native libraries for such things when running on a variety of devices, so that people who understand that specific hardware and system better than you do can deal with such specificity and you can deal with writing a good programming language.

Re:how does the patch work?

[Obfuscant]

The volatile keyword prevents the compiler from doing things like moving values into registers,

What "volatile" actually means is that the memory location underlying the variable is able to change without the CPU knowing it and thus not only can the variable not be assigned to a register (which is what the "register" keyword causes), it must be accessed anew each time it is referenced. Thus, code that says something like:

if( x==0 )

      do something;

        if( x > 0)

                do something else;

        end

end

cannot optimize out the (x>0) test and something else code if x is marked volatile.

C purists will say that you can look at code and tell exactly what assembler output it will result in, but that's a ridiculous claim on any sort of optimizing compiler--a whole lot of stuff you didn't specify goes on.

C purists stopped being able to say that a long long time ago. Or int64 time ago.

I was once using an SGI MIPS C compiler, writing code I needed to run as fast as computerly possible. I was doing all the standard and even some pretty advanced hand optimization steps and getting nowhere. I finally realized that the O3 option to the compiler was already doing pretty much everything I was doing by hand and I was wasting my time. And then I ran across an early version of the Intel C compiler which was happily optimizing out an entire chunk of code that wasn't optimizable. (It was something to do with the instruction pipeline and branch look-aheads that wasn't being handled right, not a true "optimization". That means the code was still there, just lost in the pipeline when a branch took place.) So, it is as easy to say that there is a lot of stuff going on that you didn't know about, and a lot of stuff that isn't going on that you think should be.

Re:how does the patch work?

[hawguy]

I understand why you'd use a volatile variable for something that can be touched by an external event or process, but that's not what happened here. I'm talking about this specific case involving the FPU where it was the compiler that put my variable into the FPU register, it didn't happen by some external event that the compiler had no knowledge of.

If the compiler is the one that decided to move my variable into a high precision FPU register, then shouldn't it be smart enough to convert it to the appropriate precision before doing a comparison with a variable of less precision?

Re:how does the patch work?

[TheSunborn]

But the definition of correct is not obvious when talking about floating point results which can't be represented exact.

Look at this small c function

void fun(double a,double b) {
double c=a*b; // Line 1
// Misc other code
double d=c*2; // Line 3
/*
The value of d here may differ based on compiler optimisation, because the representation of the variable c may be either 64bit or 80 bit depending on if the value were written to memory, and then read back or not between Line 1 and Line 3. And both result would be correct even if they would not be equal.
*/

}

Re:how does the patch work?

[DavidTC]

All you need is this quote:

Premature optimization is the root of all evil -Donald Knuth

Before you write code, think about how it should hypothetically be optimized, and sorta plan it out like you would if you were going to super-optimize it.

And then just write it normal, and assume the damn compiler is smarter than you. The only 'optimization' you should do is making sure stuff that can be outside loops is outside loops and that if you have some huge arrays or objects you should pass them by reference if you can. (If that advice is relevant to your language. And some languages where it is, the compiler is smart enough to know it, too, so don't do it there either.)

At that point, when you're done, if, and only if, it's slow, identify the hotspots, the time the processor spends large amounts of time on, and optimize them.

Even in a program that needs to run super-fast...does the whole thing really need to? Do the startup, does where it's loading in a file? Or is there just some tiny calculating loop in the middle that needs to run at max speed and should be optimized, and the rest of the program can waste a grand total of half a second being slower and less confusing?

Do not optimize in advance, do not attempt to optimize afterward unless it's an actual slow and much-used spot.

But you know all that now, I'm sure. It's amazing how many people learn about optimization and immediately try to 'fix' everything.

Re:how does the patch work?

[Obfuscant]

But you know all that now,

And I knew it then, which is why I was working specifically in the functions that the profiler told me were slow.

The only place I disagree with you is in the planning for optimization. I write my code so I can read it and understand it, because for MOST things I write my time is more valuable than the computer's and I don't care if a loop takes a bit longer. I don't write loops unrolled or combine constants usually, because that's harder to debug and less obvious.

This was a special case of a program that needed to keep up with a running video stream and do many things at once.

Other than that, I agree with you -- so I'll give it a 95%. It's got a beat you can dance to but the lyrics are odd.

Re:how does the patch work?

[JoelKatz]

Sure, it could do that. But that would give you a less accurate result. Why should it go to extra effort to provide a less accurate result unless some standard or specification requires it to? If you really need that, GCC does provide an option for it, '-ffloat-store'. But it has a performance and accuracy penalty.

Re:how does the patch work?

[Lisandro]

Good overview of the issue, thank you. I was wondering what the deal was with the volatile declaration on the patch submitted yesterday. I imagined it was something of the sort, though i couldn't fully grasp it.

The patch works but it's a hack, basically. Someone needs to fix their FP parser.

Re:how does the patch work?

[Anonymous Coward]

It's been a long time since I messed with x87, but I was under the impression that the 80-bit internal mode can be disabled with a flag.

Point

[Anonymous Coward]

How many servers are still on 32-bit processors? I'm sure they're out there, but Opterons were 64-bit at least 7 years ago and Xeons about 6 years ago. If you've got servers older than 6 years or are running servers on commodity hardware, OK. But is this really a widespread issue? One issue could be running 32-bit VM hosts, I suppose, on hardware that doesn't have VT extensions (and thus hosts must be 32-bit).

You tried it, didn't you? Come on now, admit it!

[j741]

I wonder how many of you read this article's summary and them immediately wrote a quick PHP script to perform this exact conversion. If you did, did you crash your machine or did you encounter a disappointing non-event?

The infamous x87

[bk2204]

The i387 (and its successors) suck as floating-point hardware; this we know. However, this bug isn't as crippling as it might seem. This bug won't affect amd64 machines running in 64-bit mode where the compiler is GCC (since GCC uses SSE2 in that case). It also won't affect any Mac OS X machines, since they made the smart move to always use SSE2 on Intel hardware since all of the Intel chips they've ever shipped support it. And I think FreeBSD uses double precision mode by default, so this probably won't affect them either, unless PHP puts the libc into extended-precision mode.

Re:Some parts of php.net search affected

[erstazi]

That server must be 32bit then as this bug is pretty much limited to 32bit versions of php (reference: http://www.exploringbinary.com/php-hangs-on-numeric-value-2-2250738585072011e-308/)

Re:You tried it, didn't you? Come on now, admit it

[Anonymous Coward]

I think some /. user did try testing this out on a variety of servers.

Seriously

[theunixman]

PHP, my days of not taking you seriously are certainly coming to a middle.

Non-event. No crash here.

[Dark$ide]

I ran this:
<php echo "start\n"; $a = (float) "2.2250738585072011e-308"; echo $a,"\n"; echo "end\n"; ?>

It got this:
[Thu Jan 06 23:30:49 2011] [error] [client 10.1.1.30] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /home/dougie/public_html/test_crud/bug.php on line 3

strtod()

[tepples]

And thread safety? It's a pure function! It doesn't need any thread safety!

strtod() has no side effects, but it still reads global variables. Does your locale use a period or a comma as a decimal point? And did another thread change the locale behind your function's back?

PUSH START TO RICH

[tepples]

FORTRAN is just too damn slow for such things.

Especially when he spends most of his time riching.

mb_internal_encoding is not defined

[tepples]

mb_internal_encoding('UTF-8');

Fatal error: mb_internal_encoding is not defined because mbstring is not enabled by default. And no, you can't install this extension on your hosting company's copy of PHP.

Re:mb_internal_encoding is not defined

[Firehed]

Get a real host. Or for an extra dollar a month or so, use any one of a great number of cloud offerings and have complete control over your installation. That same host that doesn't have multibyte support also probably has safe_mode turned on, which will cause far more problems than a bad result from strlen.

Re:You tried it, didn't you? Come on now, admit it

[Anonymous Coward]

I tried it, couldn't trigger the bug.
Of course, I'm running on 64bits systems...

Re:You tried it, didn't you? Come on now, admit it

[kennykb]

I didn't test PHP, because I never use it.

I did, however, do the responsible thing and ask myself, "does code that I maintain have a similar bug, and does its test suite validate it?" I checked the Tcl test suite, and discovered that it lacked a test for the case. I added test cases for input and output conversion of the largest positive subnormal, the smallest negative subnormal, the smallest positive normal, and the largest negative normal. (All the test cases passed, so committing them ended what I had to do.)

Tcl, too, has its own conterparts to strtod and sprintf("%g"), because it depends on float->string->float being 100% lossless and on having the string representation of a float be the shortest string that reconverts to the given number. It's quite tricky to get right; this particular corner case is the tip of the iceberg.

Ah, man...

[edibobb]

That's my favorite number.

Php popularity

[dniq]

Why is this joke of a programming language so popular is beyond me. It's a complete failure, obviously created by a bunch of first grade students who have no clear idea about syntax and uniformity. Every new version breaks compatibility with older scripts and at the same time adds more moronisms. Ugh!

Re:Hey! That's the combination to my luggage!

[d0nster]

You could always change the combination to 12345. It's always worked for me.

Worth a shot on the 'dot

[Tablizer]

$x = 2.2250738585072011e-308;
$x = 2.2250738585072011e-308;
$x = 2.2250738585072011e-308;

Re:Some parts of php.net search affected

[Tablizer]

Search http://us3.php.net/ [php.net] for 2.2250738585072011e-308 and the page hangs and then returns an error. Search for something else like 2.2250738585072011e-307 and it's fine.

Maybe because the target number is slashdotted?