"Escalate? Oh how I wish I had someone to escalate to." Classic.
Does this guy realize he's asking the founder of PHP (rasmus@php.net) to "escalate this to someone who can answer". lol
PHP Bug: #50696: number_format when passed a 0, returns null
11–20 of 51 posts
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#12Interesting 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.
I would argue that it makes a lot more sense for a non-number to return NULL than to return 0. If it returns 0, how do you distinguish between "0" and ""? At least with a NULL return value you can use the function to see if you're even looking at a number at all.
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#13This is why I hesitate to release open source software.
Because you're afraid to tell a troll on the Internet "no"?
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#14Interesting how the reason that this bug is affecting the original poster is that a new version of the language is being used. The code can't be changed because "We have number_format in literally thousands of places across 50 or 60 separate products. 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."
It seems to me that the entire process of testing and writing off is just as important when changing the target platform as it is when changing some of the API calls.
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#15Earlier quoted context omitted.
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.
I would argue that it makes a lot more sense for a non-number to return NULL than to return 0. If it returns 0, how do you distinguish between "0" and ""? At least with a NULL return value you can use the function to see if you're even looking at a number at all.
Sure. And I haven't used PHP in about a decade. But it sounds to me like this was overlooked by them and so returned 0 for many years. Despite being undocumented behavior, fixing it causes a breaking change. On my team whenever we come into this situation and realize that fixing overlooked things can actually "break" people, we really think twice about the fix. Even if in theory the fix on its own is totally the right thing to do.
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#16Re: PHP Bug: #50696: number_format when passed a 0, returns null
#17The ending (the last comment). It is epic.
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#18I don't see why it should return null.
If "" == 0, meaning "" is coerced to 0, shouldn't it coerce to 0 here too?
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#19I'm definitely on the PHP guys with this. A big criticism against PHP is that it's inconsistent in numerous ways. This bugfix is obviously part of an effort to standardize function behaviour.
Go PHP!
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#20This 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 ca…
number_format returns a string - I would expect it to return null rather than 0 for bad input