
PHP Bug: #50696: number_format when passed a 0, returns null - chaostheory
http://bugs.php.net/bug.php?id=50696
======
ddbb
Interesting 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..

~~~
city41
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.

~~~
BrandonM
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.

~~~
city41
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.

~~~
Nwallins
> _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._

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.

------
jrnkntl
"Escalate? Oh how I wish I had someone to escalate to."

Classic.

~~~
niyazpk
I like his humility. Many people in these situations would be like: "Do you
know who I am?"

~~~
jrockway
"Do you know who I am?" is probably a better answer. The "humble" answer is
just an amusing in-joke at the expense of the poster. ("Haha, look at that
dumb n00b who doesn't know who Rasmus is!" There is even a comment below that
pretty much says this exactly.)

"I'm the creator of PHP. I am not going to fix this," would have ended the
discussion much sooner and with less hurt feelings.

------
jrgnsd
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!

~~~
mbreese
But the problem with this is that those inconstancies have been around for so
long that people have come to rely on them. So when you try to "fix the
glitch", people get upset.

So, when you say it's part of an effort to standardize behavior, I think
you're right. But is this the right way to go? I mean, was the old behavior
that bad? Why not just flag it as a warning and mark it as deprecated
functionality? Then wait until version 6 to actually force the change.

I don't have a horse in this race, since I stopped using PHP when 5 was just
coming out. One of those reasons was to avoid stuff like this...

~~~
Yaa101
I do not agree, if the programmer relies on idiosyncrasies of a system then
it's the programmer's fault, no matter how long these idiosyncrasies were in
the system. It's the programmers job to anticipate on that. It is also a
fallacy to think (especially for a programmer) that your program is done when
finished, last 40 years have shown that a programmer always has to do
maintenance just like buildings and bridges and other infra.

Further I agree with what Rasmus states as one of his last remarks in that bug
thread: "Wow, a classic case of how not to treat unpaid volunteers who provide
critical pieces of your money-making infrastructure."

In other words, go make yourself a programming language if you have a big
mouth towards volunteers when you scheme of making money with their system
fails you, the bloody arrogance.

------
vlucas
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 cases and un-documented behaviors for
functionality.

~~~
rbanffy
+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.

~~~
bozmac
I wouldn't go as far as throwing an exception. A notice maybe.

~~~
rbanffy
Asking a function that formats a number and that is defined that way in the
documentation to format a string is a programming mistake. As the discussion
clearly states, it's a minor change in application code that would make it
both clearer and more robust.

I would go as far as recommend using a USB shock device to issue a warning to
the programmer every times a mistake like this is made. ;-)

------
viraptor
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 ] )"

~~~
alttab
From the documentation is correct!

Passing a string instead of a float and expecting it to behave a certain way
is undocumented. Oh my! Relying on undocumented behavior... a simple duh in
the production world.

I'm not adding to the conversation, and I realize this. But simply my $0.02.

~~~
brandon

      But simply my $NULL.
    

Oops!

------
moconnor
Although Rasmus is quite clearly right to have fixed the undefined behaviour
and is probably quite charming in person, if _anyone_ in our company responded
to one of our customers like that, well, there'd be trouble.

He could've saved himself a lot of grief if his first reply had been:

Hi,

I'm sorry to hear this change has broken your existing code. We've been
cleaning up undefined behaviours such as the one you're relying on in this
release and this particular fix has been reviewed and accepted by the
community over a 3 month period, so there's no chance to revert it now.

Going forward, you can either patch your code to stop relying on the
undocumented behaviour (e.g. cast the string to a float) or you're also free
to modify the PHP source to return to the previous behaviour - one of the
benefits of relying on an open source framework.

Best regards, Rasmus Lerdorf, creator of PHP

Sadly, this would never have appeared on HN and thus brightend up my Monday
morning.

~~~
ionfish
Presumably the people in your company aren't _unpaid volunteers_.

~~~
wendroid
> From September 2002 to November 6th 2009, he had been employed by Yahoo!
> Inc. as an Infrastructure Architecture Engineer.

Some might say "PHP developer"

~~~
ionfish
They might indeed, but the person filing the bug report in question (in their
capacity as a user of PHP, at any rate) is not a customer of Yahoo! Inc., and
thus Rasmus' employment there is irrelevant to the point at hand.

That point, rhetoric aside, is that the reporter is not party to a commercial
contract with the people who fix bugs in PHP, whoever they might happen to be.
Consequently, there should not be the "trouble" that moconnor asserted would
occur should anyone in his organisation respond to a customer in that manner.
The two parties simply do not have that relationship.

The phrase "unpaid volunteer" comes from Rasmus himself, in the bug report
under discussion: "Wow, a classic case of how not to treat unpaid volunteers
who provide critical pieces of your money-making infrastructure."

------
jedediah
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 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.

~~~
bmj
Agreed. When we update our platform, the entire product goes through
regression tests (not necessarily a full re-run of every test, though). If we
change any code to accommodate the new version, those modules are completely
re-tested.

If they write tax software and don't do any formal testing, I'd seriously
hesitate to use their product.

------
ars
I don't see why it should return null.

If "" == 0, meaning "" is coerced to 0, shouldn't it coerce to 0 here too?

~~~
kingkilr
Equality isn't transitive in PHP :/. Of course, IMO, the real coding horror
here is that in an error circumstance no exception is raised.

~~~
prodigal_erik
This. There are dozens of situations where, given instructions that simply
don't make sense, PHP arbitrarily picks some half-baked behavior instead of
giving an error. So much so that I think the original poster is out of line
for even considering _tax planning_ in a language that wants to guess what you
might have wanted to happen!

~~~
joeschmoesky
+1

------
InclinedPlane
One wonders, how would it be possible for this gentleman to work under the
onus of such a horrifically restrictive enterprise-y change control board and
yet have the ability to upgrade the toolset for 50 or 60 seperate products,
his words, without going through said onerous change control process? It seems
like there is a giant gaping hole in this company's processes, not surprising
as it sounds like a horrible place for anyone with talent to work.

------
dugmartin
This is why I hesitate to release open source software.

~~~
jrockway
Because you're afraid to tell a troll on the Internet "no"?

------
archon810
The ending (the last comment). It is epic.

~~~
Sumsar
I ran into this same problem. Reread the original bug report, ignoring the
rest. The poster respectfully made a simple query as to expected behavior.
From rasmus first response the poster was treated flippantly and with
disregard. And the poster didn't wilt, but instead answered toe to toe.
Anyway, now I have this code where user's skip answering fields (damn users!)
and my code used to fill in the zeroes (or commas in the thousands). But now
my code no worky. Will that cast to float work? I was doing this elaborate
if($in==""){0:number_format($in);} or whatever, but do I only have to cast to
float?

