Edit report at https://bugs.php.net/bug.php?id=60977&edit=1
ID: 60977 Comment by: clowns at hotmail dot com Reported by: [email protected] Summary: number_format behavior changed when passing \0 for 4th parameter. Status: Closed Type: Bug Package: Math related Operating System: OSX PHP Version: 5.4.0RC7 Block user comment: N Private report: N New Comment: @ [email protected] Wtf are you on about, presumably you're the noob who "fixed" one bug by creating a much bigger one. What you did is like fixing a bug by making php thinks 2+2=5, and you don't think this is serious enough? That's why you're the moron who create the bug the first place. You have the time, you just don't have the skill. Do the rest of the world a favor and never come back to "work" on PHP. Previous Comments: ------------------------------------------------------------------------ [2012-06-16 04:04:18] [email protected] see https://bugs.php.net/bug.php?id=62112 ------------------------------------------------------------------------ [2012-05-09 01:21:08] [email protected] 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] [email protected] 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. ------------------------------------------------------------------------ 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
