Why are you passing an empty string in place of a number there?  You 
are essentially asking for an empty string to be printed with 0 decimal 
places and you are getting back an empty string.  You also get a big 
warning about that, of course.  How about "a",0 what do you expect that 
to return?  

I think the right solution for you here is to be explicit about casting 
your weird inputs to a float.  number_format((float)$weird,'0') will 
take care of it.

I submit that you may have missed the point:

We are passing a (possibly uninitialized, or null-valued) variable to the function, in hundreds of places and web pages, and we would not expect such a fundamental function to suddenly return a different result.  What is unreasonable about expecting a "number formatting" function to default to "0" if given non-numeric or null input, *esp* since that has been the behavior since Day 1?

No, I am not missing the point.  This same behaviour could very well be 
a bug in an app as well.  If this was changed in a minor version, I'd 
agree with you on the BC change, but we have been working on catching 
these weird edge-case scenarios that lead to unexpected bugs.

This is going to cause us MONTHS or fixing code for no real benefit since this behavior change is arbitrary and seemingly, was made for no reason. We are all engineers and developershere, and can't seem to get the reasoning behind returning NULL when a number is called for in the return. 

It's not a number definition, but FORMATTING. How do you format nothing in the numerical system? By having it be zero. You don't have NULL dollars in your bank account, do you? 

Please escalate this to someone who can answer the question as to why this was changed. If no one knows, then why was default behavior changed?

Months?  Being a bit dramatic here?

sed -i "s#number_format(#number_format((float)#g" *.php

Escalate?  Oh how I wish I had someone to escalate to.  

The change was part of standardizing all of PHP on the same parameter 
parsing code.  It is called zend_parse_parameters() internally.  Most 
of PHP was using this already, but there were still some stragglers 
like number_format().

The first PHP 5.3 release candidate was back in March 2009.  We put 
these release candidates out there so people who "will have MONTHS of 
work" because of small changes can chime in then and make their case.  
The release candidate period lasted until July.

Dramatic? You've obviously never worked in a change-request-release environment. We have number_format in literally thousands of places across 50 or 60 separate products. Each of those changes will have to be coded, tested, written-off, released, tested by the clients since this is tax data and has to be precise for tax planning and retirement planning.

So, before you go belittling the developers and users depending on PHP, perhaps you should stop and think about the massive effect this change has had on us and not act so dismissive.

5.3.x was not available on our last platform, which is why we are moving to a supported, fairly-recent platform. Why you have so much anger towards this bug is not a proper way to triage or respond to user requests. We have done nothing but explain how this change will massively affect our calculations.

Our only feasible option is to patch php back to the old behavior, but my C is fairly rusty and we ran into issues with time testing the ins and outs from buffers in the number_format function in math.c

I have worked in such environments.  Much bigger ones, in fact.  Part 
of your responsibility in your position is to keep track of your tools 
and the changes coming down the pipeline.  5.3 was available to you as 
a release candidate in March of last year, and even earlier directly 
from our revision control system.  Many things have changed and there 
are many many people out there affected by these changes, we recognize 
that.  That is also why we are not likely to reverse a change like this 
that others in your situation have now accounted for, tested and 
deployed in production for many months simply because it is 
inconvenient for you.

I get it. Yours is bigger, you've worked better, you are at the cutting edge of everything, and you have infinite resources to test every new version of every piece of software in your stack. Got it. I'm shamed and have no options. So, you're going to give a cover-all answer to make sure that you don't have to do anything. Ok, I get it. I hope no one ever does this to you, because it makes you lose faith in the product.

We will push forwrd with patching the source. It would appear that the 1194th line in math.c is the one that needs changing. returning 0 as opposed to returning nothing? I'll edit and compile.

Wow, a classic case of how not to treat unpaid volunteers who provide 
critical pieces of your money-making infrastructure.

Just look in the mirror, pal.

You need classes on how to listen to others.

Sir.

This issue was recently brought to my attention.
On behalf of PHP I would like to apologize. I see that now that you have been treated unfairly.

After carefully reviewing this bug report with our board of directors on 4chan, we have come to the conclusion that your "rusty C skills" should be enough to fix the issue.
I would therefore like to remind you that rasmus@php.net is http://en.wikipedia.org/wiki/Rasmus_lerdorf

Again, I sincerely apologize. We will try to stop fixing bugs in PHP.

Fun thread! Anyway, I was wondering if anyone has a complete list of the functions 
that changed as a result of this zend_parse_parameters() fix. I don't see anything 
specific in the upgrade instructions:
  http://www.php.net/manual/en/migration53.incompatible.php

Also, will number_format((float) $x) behave under PHP 5.3.x exactly the same way 
that number_format($x) behaved under PHP 5.2.x? Are there any subtle differences?

Thanks.