#50696 [WFx]: number_format when passed a 0 as first function argument, returns null

From: Date: Fri, 08 Jan 2010 23:05:44 +0000
Subject: #50696 [WFx]: number_format when passed a 0 as first function argument, returns null
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-146462@lists.php.net to get a copy of this message
ID: 50696 User updated by: endosquid at endosquid dot com Reported By: endosquid at endosquid dot com Status: Wont fix Bug Type: Math related Operating System: Linux 32 bit PHP Version: 5.3.1 New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2010-01-08 22:47:04] rasmus@php.net 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. ------------------------------------------------------------------------ [2010-01-08 22:38:23] endosquid at endosquid dot com 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 ------------------------------------------------------------------------ [2010-01-08 22:23:41] rasmus@php.net 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. ------------------------------------------------------------------------ [2010-01-08 21:51:14] endosquid at endosquid dot com 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? ------------------------------------------------------------------------ [2010-01-08 21:39:01] rasmus@php.net 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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/50696 -- Edit this bug report at http://bugs.php.net/?id=50696&edit=1

« previous php.bugs (#146462) next »