php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: chobieeee@php.net
New email:
PHP Version: OS:

 

 [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

Pull Requests

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 
see https://bugs.php.net/bug.php?id=62112
 [2012-06-16 04:04 UTC] chobieeee@php.net
-Status: Open +Status: Closed
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Nov 22 03:01:27 2024 UTC