Edit report at https://bugs.php.net/bug.php?id=60977&edit=1

 ID:                 60977
 User updated by:    chobie...@php.net
 Reported by:        chobie...@php.net
 Summary:            number_format behavior changed when passing \0 for
                     4th parameter.
-Status:             Open
+Status:             Closed
 Type:               Bug
 Package:            Math related
 Operating System:   OSX
 PHP Version:        5.4.0RC7
 Block user comment: N
 Private report:     N

 New Comment:

see https://bugs.php.net/bug.php?id=62112


Previous Comments:
------------------------------------------------------------------------
[2012-05-09 01:21:08] ahar...@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-05-08 21:42:07] 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-08 21:35:05] 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-02-06 00:46:14] ahar...@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-04 16:58:37] 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.

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


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

    https://bugs.php.net/bug.php?id=60977


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60977&edit=1

Reply via email to