I think there are two bigger issues:

1.) Things like this should not be warnings in the first place. There should be more strict handling of invalid input so they result in actual exceptions being thrown instead of output that can be exploited in incorrect/undocumented ways.

2.) The php.net documentation for number_format doesn't even state that NULL is a possible output value. And I can't find anything in the changelogs stating when this change was made (admittedly I glanced quickly so I may have missed it)

You state that it is a bug in PHP, but I respectfully disagree. This is a bug in the varied way in which PHP returns output based on invalid input. Some functions return 0, some functions return NULL, some functions return FALSE and it seems as if it is all done arbitrarily. This really should end, invalid input should result in standard exceptions being thrown so they can be handled.

Quotes like this keep me from sleeping well at night:

> It's not a number definition, but FORMATTING. How do you format nothing in the numerical system? By having it be zero. You don't have NULL dollars in your bank account, do you?

He goes on to say that "this is tax data and has to be precise for tax planning and retirement planning."

Think about that for a minute. A guy claiming to write tax planning software doesn't know the difference between NULL and 0. NULL is not 0. It's NULL. I don't want tax software reporting that I owe "$0" instead of "$badvalue". At a minimum, I want it to throw a giant red error dialog that scares me into double-checking all my inputs.

I think he knows the difference which was why he had a problem with it. But of course the problem is not that some arbitrary function no longer returns him a preferred default value, the problem is that he is sending it garbage to begin with (and he claimed this was used in "thousands" of places...shudder).

> There should be more strict handling of invalid input so they result in actual exceptions being thrown instead of output that can be exploited in incorrect/undocumented ways.

It's trivial to turn all notices/warnings/errors into exceptions in PHP (it even provides an exception class for it, ErrorException). PHP is multi-paradigm and supports many different ways of handling errors and warnings.

> This is a bug in the varied way in which PHP returns output based on invalid input. Some functions return 0, some functions return NULL, some functions return FALSE and it seems as if it is all done arbitrarily.

This change was to make the output of functions consistent based on invalid input. It's specifically addressing this point. It's also the very first point listed in the migration documentation

http://au2.php.net/manual/en/migration53.incompatible.php

I am very aware that it is trivial to handle notices, errors and warnings. The problem is that PHP does not do this by default which allows people to exploit undocumented behavior.

As for handling invalid input, I think you should actually check what some of the functions output some day.

For example, decbin clearly states that the input should be an integer but if I pass it a string.....

Code/ctsr » php -r 'echo decbin("invalid input");' 0%

Zero is clearly not a NULL value. This is one I ran into this morning with php 5.3.8, I've seen this issue crop up in many other functions, they don't return NULL. Some return NULL, some return 0, some return '', some return '0', some return FALSE.

PHP was designed (I use the term loosely) to get dynamic websites up and running very quickly, and it's default configuration succeeds at that. So I don't think it's fair to call the loose error behavior a problem in PHP, as changing that would go against that ease of use, even if it's a problem when writing complex software with PHP.

I think a simple "use strict"-type declaration would go a long way for making software that's actually reliable rather than the barrage of set_error_handler, ini_set and related calls, but oh well, I'll file a feature request. It gets more complicated when security enters the mix (remember magic quotes?), but there are about nine thousand different frameworks which deal with that better since they're actually designed for a specific purpose.

I agree with you there and I'd be happy to see "use strict" in PHP.

Submit a ticket.

I don't have a strong opinion either way, but I don't think #1 is a given.

You describe one reasonable approach to building things: bad shit should blow up quickly, forcing fixes. But another reasonable way is working to make sure something reasonable happens. E.g., Postel's Robustness Principle: http://en.wikipedia.org/wiki/Robustness_principle

My understanding is that PHP started out as a noob-friendly page scripting language. For that kind of system, do-what-I-mean coding is reasonable. You're not trying to force amateurs to be pros; you're just trying to help them get something up and working. But maybe the PHP audience has shifted enough that the break-early-break-often approach is the right one these days.

I'm perfectly fine with the robustness principle being applied, but it seems as if it gives people who write poorly thought out projects a convenient excuse for bad design decisions. I've been using PHP since the early 4.x days, so I've seen the project change over the years and I can honestly say I don't think the robustness principle was ever consciously applied across the project, it just ended up that way. If it was a conscious decision then there would be at a very minimum a standard output for invalid input across all functions. Instead, every function returns something different (FALSE, 0, '', '0', NULL). Sometimes the output for invalid data is documented, sometimes it isn't, sometimes it changes without any notice or modification of the documentation. This doesn't seem like a design choice to me.

If they were going to take that approach, it should have returned 0 then.

I think of this as "garbage in, garbage out". The function will return a numeric value -- if you give it proper input.

On two occasions I have been asked,—"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

The headline of this post is such because it is quoting a PHP developer on a point made in a later comment on the report.

The quote was tongue in cheek.

This stuff happened over 2 years ago, and what he was referring to was an ANTICIPATED change sir.

Not one he'd run into at the time, since it had yet to be changed to something random and unexpected.

Relying on a brain damaged non documented edge case was unanticipated, not the change --which had also been in beta before release.

What kind of programmer passes "" and null on a function such as this and expects ....zero in return?

And what kind of programmer does it --as he admits-- "all around the place"?

If you give right to this guy, that's a very very short and accurate interview question --no hire.

You mistake my use of anticipated. I agree with you, I meant the change was anticipated as in "It was expected to happen". It was in the cards to happen eventually, whether it was intelligent or not.

Returning null in the math library at all just seems counter-intuitive.