PHP Bug: #50696: number_format when passed a 0, returns null
1–10 of 51 posts
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#2Interesting discussion in there, but I think the PHP guys are right on this one. You should never rely on undefined behavior of any API for mission critical code.
Always use what is documented so you don't have to cry later..
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#3"Escalate? Oh how I wish I had someone to escalate to."
Classic.
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#4"Escalate? Oh how I wish I had someone to escalate to." Classic.
I like his humility. Many people in these situations would be like: "Do you know who I am?"
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#5Interesting discussion in there, but I think the PHP guys are right on this one. You should never rely on undefined behavior of any API for mission critical code. Always use what is documented so you don't have to cry later..
When I first read it quickly I thought it sounded a fair complaint, then I saw this comment and figured I should think again. On 2nd read I picked up the subtleties re: undocumented behaviour, reason behind the change & effect reverting it would have and yes, I think I agree after all.
Different 'bug', similar theme: I'd be v. interested to hear what HN folks think about http://bugs.php.net/bug.php?id=47494. I explained the problem here: http://insomanic.me.uk/post/191397106/php-htmlspecialchars-h...
Summary: PHP 5.3 introduces a scenario where:
display_errors=off, log_errors=on => warning msg is logged (but not displayed, of course..)
display_errors=on => NO warning is logged OR displayed(?!)
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#6Interesting discussion in there, but I think the PHP guys are right on this one. You should never rely on undefined behavior of any API for mission critical code. Always use what is documented so you don't have to cry later..
I'd take the other side... but I can understand them choosing either way.
My vote for the other side is because php guys didn't document the change. Other pages show exactly what happens in strange cases - like in "If delimiter is an empty string (""), explode() will return FALSE." There's no mention about the change on http://php.net/manual/en/function.number-format.php and they list the result as "string" without any other notes. Making the function backwards compatible wouldn't hurt anyone either, because it would restore the behaviour for people using "" and would change nothing for ones using normal values all the time and ones who started casting to a number because of this change. But yes - it's pretty much php guys' call.
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#7A bit unrelated to the discussion... but will anyone be surprised if they get a couple of cents more (or less) on their retirement?
From the report: "Each of those changes will have to be coded, tested, written-off, released, tested by the clients since this is tax data and has to be precise for tax planning and retirement planning."
From the documentation: "string number_format ( float $number [, int $decimals ] )"
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#8Interesting discussion in there, but I think the PHP guys are right on this one. You should never rely on undefined behavior of any API for mission critical code. Always use what is documented so you don't have to cry later..
The PHP guys are right in the same sense a store is right that it doesn't have to take a return without a receipt. But most stores will do so anyway in order to maintain good will. Whenever we come across undocumented or undefined behavior that will change in a new release, we try very hard to not change it unless it's absolutely necessary.
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#9This is why I hesitate to release open source software.
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#10This is funny because it's not really a bug at all. I side with the PHP guys on this one. Passing in a string to a number_format function is not even proper form in the first place. I do agree that it should always default to 0 instead of null because it is a numeric function, but still. The usage is the main problem in this case - and who wants to fix a bug for an asshole anyways?
A lesson to all who rely on edge cases and un-documented behaviors for functionality.