21–30 of 51 posts
I don't see why it should return null. If "" == 0, meaning "" is coerced to 0, shouldn't it coerce to 0 here too?
This 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…
It should thrown an exception and abort the script with an ugly error traceback.
If the documentation says "float" and you can hand it a numerical string, then either the function or its documentation have a bug that needs correcting.
"Escalate? Oh how I wish I had someone to escalate to." Classic.
This clueless guy is one of the (wild guess) 5% of PHP users who can file a bug report and follow it...
A 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 ] )"
Earlier quoted context omitted.
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 righ…
Answered in the 2nd comment from Rasmus:
If this was changed in a minor version, I'd agree with you on the BC change, but we have been working on catching these weird edge-case scenarios that lead to unexpected bugs.
i.e. they thought about it and decided this version was an acceptable one for making breaking changes.
I don't see why it should return null. If "" == 0, meaning "" is coerced to 0, shouldn't it coerce to 0 here too?
Equality isn't transitive in PHP :/. Of course, IMO, the real coding horror here is that in an error circumstance no exception is raised.
Interesting 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 reti…
If they write tax software and don't do any formal testing, I'd seriously hesitate to use their product.
A 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 ] )"
A couple of cents off individually might not matter. A couple of cents off cumulatively across a few hundred thousand individuals over a few years does matter.
I'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!
This 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…
+1. It should thrown an exception and abort the script with an ugly error traceback. If the documentation says "float" and you can hand it a numerical string, then either the function or its documentation have a bug that needs correcting.