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:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2010-01-08 21:26:27] endosquid at endosquid dot com
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?
------------------------------------------------------------------------
[2010-01-08 19:20:29] rasmus@php.net
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.
------------------------------------------------------------------------
[2010-01-08 19:13:41] endosquid at endosquid dot com
Description:
------------
php -r 2>/dev/null 'print number_format("",0) . "\n";'
on our old PHP 5.1.6 Solaris 8 box (that we are transitioning off of)
returns 0.
Now, we're testing our code, and we run into this behavior change:
php -r 2>/dev/null 'print number_format("",0) . "\n";'
on our new RHEL5 with 5.3.1 from the REMI repository returns NULL. Is
this the default behavior expected? If so, why did this change happen?
If not, where did we go wrong?
Reproduce code:
---------------
php -r 2>/dev/null 'print number_format("",0) . "\n";'
Expected result:
----------------
We expect to see 0 returned, not NULL.
Actual result:
--------------
NULL is returned.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=50696&edit=1