Bug #60977 [Opn->Csd]: number_format behavior changed when passing \0 for 4th parameter.

From: Date: Sat, 16 Jun 2012 04:04:18 +0000
Subject: Bug #60977 [Opn->Csd]: number_format behavior changed when passing \0 for 4th parameter.
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-171302@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=60977&edit=1

 ID:                 60977
 User updated by:    chobieeee@php.net
 Reported by:        chobieeee@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] 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-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] 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-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


Thread (8 messages)

« previous php.bugs (#171302) next »