php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60977 number_format behavior changed when passing \0 for 4th parameter.
Submitted: 2012-02-04 15:58 UTC Modified: 2012-06-16 04:04 UTC
Votes:4
Avg. Score:5.0 ± 0.0
Reproduced:4 of 4 (100.0%)
Same Version:4 (100.0%)
Same OS:1 (25.0%)
From: chobieeee@php.net Assigned:
Status: Closed Package: Math related
PHP Version: 5.4.0RC7 OS: OSX
Private report: No CVE-ID: None
 [2012-02-04 15:58 UTC] chobieeee@php.net
Description:
------------
when I run the test code on php5.3. php returns `1328370011.72399998`.
but in php5.4 that returns `1`.

i don't know which behavior is correct. i think it should be returns same result.

Test script:
---------------
<?php
echo number_format(1328370011.724,"8",".", "\0");

Expected result:
----------------
1328370011.72399998

Actual result:
--------------
1

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-02-04 16:58 UTC] php-dev at zerocue dot com
This is interesting, I would think that the 5_4 functionality is more correct, 
because you're adding a null character as the thousands separator so the string is 
becoming: 
1\0328\0370\0011.72399998

Internally a null character terminates a C style string.  I would think the 
appropriate fix would be to limit the fourth parameter to displayable characters.

This probably changed as a result of a bugfix somewhere.
 [2012-02-06 00:46 UTC] aharvey@php.net
Ouch, this one's my fault, as it came in with the fix for request #53457 in 
revision 305937. (char) 0 was previously used to signal no separator, whereas 
now the lack of a separator actually signals no separator. Unfortunately, I 
didn't take into account that _php_math_number_format() returns a C string, and 
is hence null-terminated as a result.

The right fix here (which I'll work up and commit to trunk) is to change 
_php_math_number_format() and _php_math_number_format_ex() to return a zval, or 
at least have some other way of signalling the string length to the caller. 
Unfortunately, as this would break the ABI, about the best I can do for 5.4 is 
to emulate the old behaviour when the decimal point or thousands separator 
includes a null byte (which is to ignore it altogether: the 5.3 output doesn't 
actually include any nulls).

I don't think this is going to be considered serious enough to be included in 
5.4.0, given we're in code freeze, but I'll put together a patch and attach it 
here before committing it post-5.4.0.
 [2012-02-06 00:46 UTC] aharvey@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: aharvey
 [2012-05-08 21:35 UTC] dslgjkdg at hotmail dot com
3 months later, any news on the fix? This bug makes phpredis zadd useless:
https://github.com/nicolasff/phpredis/issues/113
 [2012-05-08 21:42 UTC] clowns at hotmail dot com
"I don't think this is going to be considered serious enough"

You mean making PHP thinks 1000000 equals to 1 is not a serious bug? Do you know how many extensions/plugins uses number_format on number larger than 999?

What a joke.
 [2012-05-09 01:21 UTC] aharvey@php.net
-Status: Assigned +Status: Open -Assigned To: aharvey +Assigned To:
 [2012-05-09 01:21 UTC] aharvey@php.net
I'm sorry, I don't have any time for PHP work for the forseeable future. 
Unassigning myself.

@clowns: Presumably you don't understand the concept of a code freeze.
 [2012-06-16 04:04 UTC] chobieeee@php.net
-Status: Open +Status: Closed
 
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Thu Feb 09 02:05:49 2023 UTC