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

From: Date: Fri, 08 Jan 2010 23:20:14 +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-146464@lists.php.net to get a copy of this message
 ID:               50696
 Updated by:       rasmus@php.net
 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:

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


Previous Comments:
------------------------------------------------------------------------

[2010-01-08 23:05:43] endosquid at endosquid dot com

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.

------------------------------------------------------------------------

[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?

------------------------------------------------------------------------

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



Thread (21 messages)

« previous php.bugs (#146464) next »