Hacker News new | past | comments | ask | show | jobs | submit login
We will try to stop fixing bugs in PHP (php.net)
382 points by robbiet480 on June 22, 2012 | hide | past | web | favorite | 300 comments

Leaving aside the irony of asking Rasmus to escalate the issue (this would be like complaining in an "Ask HN:" and suggesting that pg escalate the issue up the ycombinator chain), or whether the change was logical or not, I learned something cool from one aspect of Rasmus' response:

... there are many many people out there affected by these changes, we recognize that. That is also why we are not likely to reverse a change like this that others in your situation have now accounted for, tested and deployed in production for many months ... -- rasmus.

Good decisions don't always mean everyone goes home happy. Whether or not the change was good or bad, reversing it now could negatively impact anyone else who already adjusted. If it means "MONTHS" of work for this guy, in order to save "MONTHS" of work for 100 others who use PHP, so be it.

Even if we were to take a leap of faith and assume it was a bad decision by Rasmus to make the change in the first place, it's been done. Responding to inconsistency with more changes seems like trying to regain your balance by making wilder and wilder swings of your arms.

A possible solution to this would be to put a policy together to only fix things like this in the next major version, not on the current line.

As long as it's known that these are long term fixes people can prepare for them.

"The first PHP 5.3 release candidate was back in March 2009. We put these release candidates out there so people who "will have MONTHS of work" because of small changes can chime in then and make their case. The release candidate period lasted until July."

I love to hate PHP-the-language as much as the next guy, and I don't particularly love their design decisions for the language, but let's face it, on basic release management grounds there's nothing to complain about. On general principles I'm of the opinion that the PHP project did everything called for here and the fault is pretty much 100% on the user's side here, with the only possible counterargument being that they apparently may not have called this exact change out quite as precisely as they could have (though that implies they knew, which, well, in a sloppy-type language like this this sort of thing is easy to miss). Languages don't get to version 5 without some breaking changes, but the alternative of every language being stuck with every bad decision made in version 1 forever is worse.

I once played with continuous testing using a python fresh from the Hg repo. Once you set up your CI/CT box with enough compute power there is no reason to always check your product against the upstream pre-release components.

Now that I remember it, it was a pretty nice setup - creating OpenVZ partitions from a template, making python from sources and testing the application within the machine. Too bad it was a one-off thing. I should have used something like buildbot or jenkins.

That is a wonderful idea. Knowing now if your stuff will or will not break in the "future" seems worth the investment. If anyone else is doing this, I would love to see details.

There will be a couple false positives, but, in any case, you can measure the upstream development quality, and use that as an input to guide your decisions.

You're likely talking about the general case, not the OP, but I'd just like to point out that the submitter of the bug report was jumping from 5.1.6 to 5.3.1 (not to mention changing from Solaris to Red Hat, which could have its own issues) when he found this "error". 5.x releases are de facto "major" versions, even if only the minor version number changes.

It's entirely possible that this fix was made in a point release - it didn't jump out at me in the changelog, and I didn't feel like digging - but that's a moot point in this case, since even if the change was made with a major release like 5.3 this guy would still be upset.

Responding to inconsistency with more changes seems like trying to regain your balance by making wilder and wilder swings of your arms.

A better solution? Don't make arbitrary changes that will make months of unnecessary work for people for no reason to begin with. If you're going to eat up developer time, you should make it for a good reason.

"The change was part of standardizing all of PHP on the same parameter parsing code." is not an 'arbitrary change' 'for no reason'.

Even if the reason is making PHP more consistent and paying off technical debt for future PHP maintenance, instead of benefitting you directly, it's still a reasonable change for a reasonable reason.

No serious developer would lose months of work to this, that claim is completely ludicrous.

if you can't do that trivial change on some convulated release system... You don't change php version either. Unless you are addressing security changes.

I think its very professional to not bump versions just for the sake of it.

release notes exist for a reason.

As far as I understood, the release notes were not very explicit or complete (the list of impacted functions were missing) on this issue.

Recently I have encountered a problem with redhat migration: /usr/bin/X11/xwd was "moved" to /usr/bin/xwd. I have not found anything in the release note.

It is not enough to ask people to read the release notes, these release notes should be complete and usable.

The point is that the release notes will tell you if there are security flaws fixed.

There's no substitute for actually testing your code with a new environment before deploying it.

Well, of course they must be addressing security changes! It's PHP, remember? ;)

There are countless reasons to bash on PHP because, frankly, it is a pretty terrible language[1]. However, this is not a valid reason. The bug reporter is being idiotic and needlessly disrespectful, and is making a big deal out of something that can be easily fixed with a simple `sed` command, as Rasmus demonstrated.

And, to be honest, he is clearly demonstrating the fact that he's a pretty poor developer, and that he doesn't have the necessary qualifications to be writing software that manages people's retirement funds. Also, when dealing with something as important as that, you ought to know better than to base our technology on top of PHP.

[1]: Coming from somebody who built a very successful startup on top of PHP.

What shocks me most is the sense of entitlement. They downloaded PHP, its behavior changes and they'd rather complain to those who changed it and annoy them until the thing works for them again than fix the bug in their code. If they are not happy with the free product and the free support, there are other options.

PHP has its shortcomings, but, as in any open source product, if it doesn't work for you, you have a couple options.

Problem is, at that point you have built a lot of business on top of it. So the issue of whether or not it is "free" is moot because it has a very real dollar value to you and also probably to the boss who is breathing down your neck.

Then they have a couple options: fork and keep their own fork, they can pay the PHP community (or someone in it) to change it back (or to provide a backwards-compatibility mechanism) or pay developers to change their software to work with newer versions of PHP.

They can't bully their way like they tried.

> they can pay the PHP community (or someone in it) to change it back

The decision was defended on its own merit, so I would be really disappointed if bringing money to the table affected the outcome. Funding open source development is great as long as meritocracy is maintained. That's why Linus never accepted a job at a company that had a stake in pushing Linux in a certain direction.

If they could prove that the change would create a really huge expenditure and would thus damage the community, I assume a workaround could be reached through the normal democratic decision process. I imagine a config option to restore the original functionality would be a nice solution, but I'd suggest the company should fund its development (along with proper tests and associated code).

If they kept config files to control every altered behaviour PHP configuration would be an even bigger mess than it is already.

PHP has its shortcomings, but, as in any open source product, if it doesn't work for you, you have a couple options.

I personally think this guy should ask for a full money-back refund and then shut the hell up.

More than once I suggested that. I used to work at an ISP that offered free e-mail accounts and webmail.

It's really hard to not blame the creators when SO MANY things in PHP are fucked up. I would wager a good bit of cash that this isn't the only "wtf-moment" this guy's dealing with in terms of his day-to-day PHP adventures, and it was simply the straw that broke the camels back. Couple that with an innate misunderstanding of how open source works and a bit of idiocy, and you got the motivation for this bug report.

A bit off-topic: As someone who has built a decent web company on top of PHP, I'm curious to know if you decided to leave it for something else and if so, what was your reasoning?

I'm of the mindset to stick with what I know best when I'd rather build a working product and get it out the door quickly. I don't actually personally care too much what language I use (I feel like database selection is more crucial) but I read about so many startups running on Python or Rails that I'm starting to wonder if there's something I'm missing and if there are business advantages to using other languages/frameworks.

This essay has been referenced over and over here, but have yet another link: http://paulgraham.com/avg.html Check out the whole thing, the money quote for this context is: "Back in 1995, we knew something that I don't think our competitors understood, and few understand even now: when you're writing software that only has to run on your own servers, you can use any language you want."

Contrary to the other comment, there are business advantages to using a particular language. (Though I would concede if your only choices are Ruby's Rails, Python's Django, and PHP's Yii, for many problems there isn't much to compel you to one or the other besides your preference and available talent.) I could write a large comment going over the pros/cons for different use-cases of PHP (plain or with a framework like Yii), Python (with Flask), Java (with enunciate), and Node.JS (those are the only languages/environments I've built larger-than-toy webapps with; I still need an excuse to use Clojure's Noir for something). My list would not just be language-war pros/cons but business value considerations and hypothetical consequences. It's not the most important choice you can make, but it should be considered if there's more than one option because the type of problem you're solving can be made much simpler or easier with the right tool.

I think you've got the right mindset, and that's to use what you know for anything important you need to finish soon, but I'd recommend checking out the other environments on your own time just for fun. Also before starting a project, research to see if it's a solved (or mostly solved) problem for another framework/language. Even if there's a learning cost to something brand new, depending on the problem it can be well worth it for the overall cost reduction that the tool provides. There are a lot of "We learned and used/migrated to Erlang" stories out there because Erlang solves particular problems very well.

I would be interested in reading a blog post which details your experiences and business decisions behind all of the frameworks you have mentioned.

I often find myself wanting to start new projects in $new_platform but have no idea how to really compare them before I get started, save for looking at their documentation or advertised features.

There is no business advantages at using Python/Rails over PHP. (and vice versa)

You should only use the technology that suits your company the best (in terms of needs and knowledge -never EVER start a company based on a tech you don't understand or know)

Depends. The availability of open-source libraries in a language can be a big advantage.

"Also, when dealing with something as important as that, you ought to know better than to base our technology on top of PHP."

Upon reading the conversation I was amazed he didn't get that response right away.

Love this snippet:

> > Please escalate this to someone who can answer the question as to why this was changed. -- endosquid at endosquid dot com

> Escalate? Oh how I wish I had someone to escalate to. -- rasmus@php.net

Rasmus comes across as a little kid.

Here's how I read it:

We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code so if it breaks your stuff then tough shit because we're a bunch of amateurs.

I especially liked this quote: "Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure."

Perhaps it isn't about being paid, but about taking pride in the work you do.

PHP is convenient. I use it for some piddly shit because that's what it's good for. This bug report highlights the problems you run into if you use it for serious work.

"I use it for some piddly shit because that's what it's good for."

The bigotry from this community when it comes to PHP has left me sick to my stomach.

Don't sweat it.

Some of the people who raise the biggest fuss about PHP are also people who never dealt with it (except through Wordpress).

I mostly program in Python these days, but I used PHP for years beforehand without much drama. I even enjoyed it at times. Yes, I do have a Comp Sci bachelors degree and I probably should care more - but I found it a lot more interesting not to have to deal with fiddling around with servers in order to perform my job.

The critiques of the language aren't baseless, but plenty of large startups manage to do just fine with PHP.

TLDR: Languages are meaningless penis measuring contests of the IT world. If you will ship faster and better with language X, go ahead and use it.

> If you will ship faster and better with language X, go ahead and use it.

Absolutely, by all means, go for it. Godspeed.

> Languages are meaningless penis measuring contests of the IT world.

No they're not, and this is just insulting. I'm only an amateur PL nerd but there are people who have devoted their lives and careers to studying languages and thinking about the differences between them and how to design something practical, consistent, logically sound, beautiful, etc. To brush aside that work as meaningless is pretty narrow-minded. After all, some of that work helped even lowly PHP to stand taller on the shoulders of giants, and make it even possible to be a reasonable tool.

He meant that not in the context of Language Research, which is super-awesome and every developer should be super grateful to researches in this space, but in applied programming, where people piss on whatever language they aren't used to using/think sucks for some arbitrary reason.

But the lines between research and industry or "applied programming" aren't that clear cut (look at how much Rich Hickey's been able to mine the veins of research and bring awesome ideas to a practical and well-designed language like Clojure). I think some healthy debate, which includes pointing out languages that have severe flaws, is important and I wouldn't want to discourage it from happening, especially not on HN. I certainly don't think it needs to be dismissed as "meaningless penis measuring contests". That debate should definitely be carried out politely, of course. I'm not defending incoherent language flame wars.

"healthy debate" Yes! This is what we do need, what we do NOT need is bullshit like "piddly shit" which you seemed to be defending.

But please, tell me of one, just one, "severe flaw" you find in PHP, as it is today. And I will enter into a healthy debate with you.

I'll bite. PHP's automatic type conversion is a severe flaw.

The intent was to make it easier for beginners to pick up the language without worrying about technical details like types, but it violates the "fail fast" principle. It might make it easier for beginners to write code that works some of the time, but at a cost of making it harder to write code that doesn't break in surprising ways later. It's not just that automatic coercion exists, but that the behavior is biased toward returning values that don't produce errors. Treating the string "three" as equal to the number 0 is very unlikely to be the desired behavior. Even if not emitting an error is desired, a contagious NaN value would make a lot more sense.

There are certainly ways for an experienced user to mitigate the problem, but beginners don't know them, using them effectively requires discipline and a great deal of production code doesn't use them. The latter problem is cultural, but the language being tolerant of sloppy code naturally attracts people who write sloppy code to the language.

No, I absolutely was not defending language like "piddly shit". I was attacking language like "meaningless penis measuring contest". I think neither has a place on HN.

I have nothing to say about PHP (because I've never used it) I was reacting to a specific comment in jbm's post, which generalized languages and debates around them. Sorry for derailing the thread from the topic of PHP, and I probably shouldn't have made a little dig with "severe flaw".

Which is why you should use Python, not PHP ;) (Penis submitted for measurement)

words full of wisdom, sir

>Some of the people who raise the biggest fuss about PHP are also people who never dealt with it (except through Wordpress).

That's clearly nonsense. The people who point out how terrible PHP is have huge, very detailed and very accurate lists of the problems with PHP. They don't get that from "never dealing with it".

>If you will ship faster and better with language X, go ahead and use it.

We do. Why do you think that means we shouldn't point out how bad PHP is? Did you know that for every stubborn dumbass that sticks his fingers in his ears and screams "LALALALA I CAN'T HEAR YOU!", there's an inexperienced developer who didn't know how bad PHP was or why, who was inspired to learn more because of that "PHP bashing" post, and who subsequently saved years of hardship by switching to a sane language? Just because you don't want to hear about how shitty PHP is, doesn't mean nobody else does.

Actually, most of those lists are based on PHP4 or older (meaning their opinions are fully eight years out of date; a LOT has changed) or are made irrelevant by changing one or two quite well-documented confit settings. The little that's left over are mostly complains that PHP isnt something that it's not trying to be (strongly typed, most commonly)

The only legitimate complaints I read as someone who uses an up-to-date version tend to revolve around the wildly inconsistent naming conventions, and a couple of extensions with rather poor documentation. The recent releases (5.3, 5.4) really did a lot to make it just as feature rich as other scripting languages.

If you want to use something else, be my guest. But I for one am tired of the misinformation that PHP bashers spread. I happen to like a language that doesn't get in my way, has extremely thorough documentation, and almost any question is answered in the first search result. At the same time, I hate the lack of documentation on the actual source (I have a few things that are a huge pain to do in user land, so writing a native extension is a huge pain), and of course the wacky parameters and return values on the old functions.

>Actually, most of those lists are based on PHP4 or older (meaning their opinions are fully eight years out of date; a LOT has changed) or are made irrelevant by changing one or two quite well-documented confit settings. The little that's left over are mostly complains that PHP isnt something that it's not trying to be (strongly typed, most commonly)

Sounds an awful lot like you are just ignoring the things you don't want to hear. It isn't just that PHP is weakly typed, it is that it has absurd type conversions that no other weakly typed language does, that aren't even consistent, and explicit casts don't serve the expected purpose of forcing the correct type:

    "1e1" == "10" => True

    $a = "foo"; $b = 0; $c = "bar";
    $a == $b => True
    $b == $c => True
    $a == $c => False

    "22 cream puffs" == "22 bullfrogs" => False
    "12 zombies" + "10 young ladies" == "22 cream puffs" => True

    (string)"false" == (int)0 => True
PHP is full of bugs. Ancient bugs that have existed since PHP3, and which are still there. Serious bugs where the lexer or parser is outright broken:

    $ perl -le 'print 07'
    $ perl -le 'print 08'
    Illegal octal digit '8' at -e line 1, at end of line
    Execution of -e aborted due to compilation errors.
    $ python -c 'print 07'
    $ python -c 'print 08'
     File "", line 1
        print 08
    SyntaxError: invalid token
    $ php -r 'print 07;'    
    $ php -r 'print 08;'
    $ perl -le '$foo = 1; print(($foo == 1) ? "uno" : ($foo == 2) ? "dos" : "tres");'
    $ php -r '$foo = 1; print(($foo == 1) ? "uno" : ($foo == 2) ? "dos" : "tres");'
PHP is written by absolutely incompetent developers. There were 37 exploitable vulnerabilities in 2011. Compare that to 3 for python, 3 for perl, and 7 for ruby. Steffan Esser was the only person attempting to make the PHP project give a shit about security, and he ended up giving up on it because the other PHP devs absolutely refused to consider security as important.

These are not problems that are fixed in recent versions of PHP. They are not misinformation. If you want to revel in your ignorance, feel free. But don't expect the rest of the world to tip toe around the facts to avoid inconveniencing you with reality.

"Some of the people who raise the biggest fuss about PHP are also people who never dealt with it (except through Wordpress)."

Well that's the biggest piece of bullshit I've ever seen spewing out of someone's keyboard here on HN. I've been developing in PHP pretty much since it came out. At least, since it was stable/useful enough for people other than Rasmus to use. I've been using it for so long that I absolutely hate it. The inconsistencies, the "bolted-on" OOP, the amount of time I'm just sitting there scratching my head wondering where the fuck my data went to, and not even being able to test the thing since there's no good testing libraries built for PHP. It's all a confusing mess that I refuse to even be paid for at this point.

Use the best tool for the job.

Often, the best tool in web software is the one you can get the most/cheapest labor for so you can actually get your product completed and on the market.

No one cares if your software is programed in the latest tech with the very best techniques - all they care about is if your business is viable. PHP fills this niche excellently.

As a developer I make my living off PHP. I'd rather play with nicer languages, but frankly that isn't where the money is where I am.

Every php job can be turned into a rails/django/whatever job, you just need to sell it.

Don't get me wrong, PHP is a joke of a language, but I don't see Rasmus as the one behaving childishly here, and I also don't think he's in the wrong. APIs are allowed to change in major releases, and the behavior the plaintiff was relying on was so clearly broken it boggles the mind that he would riddle his code with dependencies on it.

> APIs are allowed to change in major releases

On the other hand, significant breakage of 10 years-old APIs with not even release notes...

Even given that it was undefined behaviour to start with, it's the very first incompatible change listed at http://au2.php.net/manual/en/migration53.incompatible.php — you'd hope a professional developer would at least glance at that document when migrating a codebase to 5.3.

> Even given that it was undefined behaviour to start with

On the other hand, 1. high-level languages have no reason to have UBs, especially for the trivial calling of a core function and 2. one could expect behavior in this context to be coherent with behavior in userland contexts. In PHP, using strings in a numeric context wasn't — last time I checked — considered abnormal, no matter how little sense it makes. One could therefore expect the relevant coercitive calls to be performed as they would usually be.

> it's the very first incompatible change listed

It is very ambiguously worded: the clause states functions will return NULL when passed incompatible parameters, but in all of PHP's userland code strings are very much compatible with floats. I would therefore submit that — in the context of being a user of PHP — the clause does not apply to this case as the value passed in is absolutely compatible with parameter expectations.

"high-level languages have no reason to have UBs, especially for the trivial calling of a core function"

What should a lisp implementation return when (car '()) is evaluated? How does a arbitrarily chosen return value differ from a undefined behavior?

Is "" -> 0 a standard conversion in PHP? I get it if we consider the groups (String, +) and (Float, +), but 0 is hardly the standard identity value.

> How does a arbitrarily chosen return value differ from a undefined behavior?

In it being defined, don't you think?

> Is "" -> 0 a standard conversion in PHP?

Erm... yes? `(float)""` returns that, `"" + ""` returns that, `0 + ""` returns that, and so do `intval('')`, `(int)''` or `floatval('')`. More generally, http://www.php.net/manual/en/language.types.string.php#langu...:

> When a string is evaluated in a numeric context, the resulting value and type are determined as follows [...] The value is given by the initial portion of the string. If the string starts with valid numeric data, this will be the value used. Otherwise, the value will be 0 (zero).

> 0 is hardly the standard identity value.

0 remains the standard and defined numeric value of an arbitrary string not prefixed with numeric data in PHP.

If a function in case of bad inputs returns a value in it's codomain, you can't distinguish it from a value returned by a normal call (except in cases where it falls outside of the functions image). This in my opinion is same as undefined behavior. Don't trust the value returned, if inputs were bad.

You know, I didn't actually know that. Thank you for enlightening me.

tools shouldn't rely on undocumented behavior when passing out-of-spec parameters into functions. Relying on such behavior eventually gets you what you deserve.

Or one could expect the language to behave coherently (tall orders for PHP, I know) and consider that it will use whatever is provided to it in the usual manner in which it treats non-numbers in a number context. Especially when the function has behaved in this manner for a decade.

As you note, one of the problems most cited with PHP is core language functions behaving in a non-coherent/non-consistent manor. This change was in-fact to bring this particular function in line with most of the others, i.e. to make it behave more coherently/consistently. It was documented, done in a major release, and done alongside a number of other (well publicised) breaking changes. Not everyone is going to be happy when things change, but I think this was a sensible development decision for the PHP team.

> This change was in-fact to bring this particular function in line with most of the others, i.e. to make it behave more coherently/consistently.

Well technically I believe it was done to unify argument parsing, but so far so good.

> to make it behave more coherently/consistently.

except this made all argument parsing (and especially this function) less coherent and consistent with PHP-the-actual-language: in PHP userland code, a string in a numeric concept will be implicitly converted to a number (to 0 if it is not prefixed by digits). This function used to behave coherently with PHP itself, as a language. Now it doesn't anymore. So all built-ins behave one way, the language itself behaves in the opposite way.

> It was documented

Not really, there was a note indicating plenty of shit broke (and it was ambiguous, the note says things about passing in incompatible parameters, but as far as PHP-the-language goes strings are compatible with floats), not listing functions which broke and in which manner.

With regards to consistency, aside from the fact that I don't think its easy or necessary to compare how functions deal with arguments to how syntax operators etc. deal with values, the situation prior to this change was that there was no consistency even within core functions themselves, before you even start to consider the rest of the language. This could have been resolved by changing all the other functions rather than these few, but that would have messed up a lot more userland code than this change did. I think it was the most pragmatic way of dealing with the issue.

With regards to the documentation, I'll concede that it could have been better. The previous behaviour was undefined and completely undocumented, so I think there are lessons for both "sides", 1) for the PHP team : fully document all changes, even to previously undefined/undocumented cases 2) for the users : don't implement functions in ways that are not documented (and/or santize input/validate output from functions used in such ways).

Also I don't think its strictly correct to say that strings "are compatible" with floats in PHP, rather that in most (but not all) cases strings will be treated/parsed down as floats.

> This could have been resolved by changing all the other functions rather than these few

What "these few"? As far as I know there is no list of the functions impacted by the change, how do you define that there's just a few versus not just a few of others?

> but that would have messed up a lot more userland code than this change did.

Because ponies? Where does that arbitrary and unsupported assertion come from exactly?

> I think it was the most pragmatic way of dealing with the issue.

Why? And why was it an issue in the first place?

> The previous behaviour was undefined and completely undocumented

The previous behavior was implementation-defined (as pretty much all of PHP is) and had been stable for a decade. And as I noted above, it was also coherent with userland behavior of PHP when dealing with strings in numerical contexts.

> Also I don't think its strictly correct to say that strings "are compatible" with floats in PHP, rather that in most (but not all) cases strings will be treated/parsed down as floats.

Which, for all intents and purposes, mean they're compatible with floats in most numeric contexts.

From the bug thread that this story refers to, Rasmus states "Most of PHP was using this already, but there were still some stragglers like number_format()". I think my arguments regarding impact of the change are a reasonable extrapolation from that.

Why was it pragmatic? Why was it an issue? There was inconsistency in the ways that functions handled parsing, and many people didn't want that feeling it made it harder to code correctly/consistently, thus it was an issue (part of the greater issue of inconsistency across a number of aspects of PHP). For others it wasn't an issue, which is why a pragmatic solution is the best that could be hoped for, not everyone would agree/like the outcome whatever was done (or not done). I can't see any other way of taking the language forward whilst causing minimum impact to users, which is why I (not you) think it was the most pragmatic way.

Every piece of code we write is "implementation-defined", including the bugs. It wasn't coherent with most other function implementations. Users couldn't reliably treat functions in the same way. I agree it wasn't coherent with numerical operations, but to get that consistency you would have to change a whole load more functions, and you would get many more complaints like this one.

"For all intents and purposes" - I think this discussion (and the many others that have featured on HN talking about similar issues of the weakly typed nature of PHP, such as == vs === ) show that it there are real world consequences to treating strings and numbers as compatible.

...of undocumented behaviour.

sed s/PHP/Ruby/g :)

> We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code so if it breaks your stuff then tough shit because we're a bunch of amateurs.

Well that's pretty much PHP in a nutshell, no news there.

I'm pretty disappointed to see comments like these around here, and not getting downvoted. This comment adds nothing to the conversation, and criticizes PHP with no factual basis or explanation.

Why? He said that the design principle of this method is in line with the rest of PHP, that's a correct and valid observation.

So how would you propose changes are made to an "API"? Never? The change was made in a new version, with the changes clearly laid out in the changelog .. what more do you want?

It's funny. PHP gets a bashing for the rotten bits .. when the rottern bits get patched up it gets a bashing for breaking BC.

Anyway, I don't think you understand just how empty that attack was. Frankly it was nothing more than the ramblings of an obviously very inexperienced developer.

“Patching up” would suggest that they actually improved the situation.

If you had read the diff you would realize they did not.

The change was an improvement .. I'm not sure what point you are trying to make? Maybe I misunderstood you or you don't understand the change.

Bad code style will eventually get you in trouble in any language or environment, bugs can occasionally turn into features and updates will always require testing, this is not a PHP specific problem at all.

"This bug report highlights the problems you run into if you use it for serious work"

Why? Because they fix bugs that break backwards compatibility? What's your point? That to do "serious work" you need a language that never changes or that you need a language that gets everything right the first time?

Of course can do whatever you want in PHP, you just need to account for its faults and shortcomings. If you cant do that, no language is going to save you.

It is not about getting everything right the first time,it's about getting the basic things right the first time.

"This bug report highlights the problems you run into if you use it for serious work."

Indeed. Passing an empty string for a parameter which is expected to be a float is SUCH serious work.

"if it breaks your stuff then tough shit because we're a bunch of amateurs."

You say that, but it rather seems like it broke amateur code.

Unfortunately PHP is consistently inconsistent. It lets people do that, and it won't ever break. Until they "make it right".

Sure the guy didn't test the parameter as being empty, but if you pass a string instead of a float, an error should be raised, and that never happened until the fix. That's the big problem with PHP :/

"Sure the guy didn't test the parameter as being empty, but if you pass a string instead of a float, an error should be raised"

Just like you should not pass strings in place of numbers, in accounting software of all things. Why can't just everbody get it absolutely right the first time?

Any language that can do anything also allows you to shoot yourself in the foot. And I think that was the case here, brainless programming; PHP hardly pulled out the rug under something reasonable in this case, they simply defined previously undefined behaviour... and when that happens, that always breaks crappy programs that depended on it, no matter in what language they're written. It's the big problem with idiots; PHP has nothing to do with it.

>Just like you should not pass strings in place of numbers, in accounting software of all things. Why can't just everbody get it absolutely right the first time?

Because the input is a text box? Text is, after all, the way for people to input data into a computer.

It stills shows a lack of rigour on the part of the developer. A simple "empty()" and "is_numeric()" check should be done on any user input expecting a float BEFORE you pass it off to a number formatting function expecting a float.

In PHP every code is amateur code.

While PHP is full of inconsistencies, it's far fetched to make a claim like this. Take a look at Symfony2 and try saying that it's amateur code.

I think the actual translation is: "You're writing retirement planning software and you can't even handle changing a method call that's been patched to a version of your own creation which preserves the legacy behavior? Get a new job."

> I use it for some piddly shit because that's what it's good for

So do Facebook.

And his point still stands. :) Could not resist.

I know you're joking, but his point is very badly made. Anything that can support ~1 billion users is not piddly. Facebook are doing amazing work with PHP, as are many others at a very large scale.

Why the unpaid work of Rasmus and many, many other open source contributors like him, who's hard work facilitated the growth of massive web sites like Facebook, is constantly being ridiculed on threads like this is sickening.

"Facebook uses it, it can't be all bad!" is a stupid argument. Because the rest of us have to deal with PHP's not-Facebooks, whose flaws are made more frustrating because of shit tooling and the systematic encouragement of shit practices in the writing of code.

It is too bad if people complaining about PHP makes someone feel bad.

What's really important here is that people need to be aware when they are adopting a tool which brings this much technical liability.

People should not be unknowingly exposed to this relentless stream of years-old, fatal bugs. Life is too short and it's even more unfair to newbies to make them deal with nutty, random issues like 'can't use a Turkish locale'. This isn't just picking on PHP. These bugs are epic and breathtaking and impose an exceptionally high amount of effort to work around.

It is clear by now that (A) these are not just a few isolated bugs but a big pile (B) most of this pile is old and already known for years (C) the PHP team is not fixing the pile despite lots of time (D) it would be such an epic amount of work to fix that you could never reasonably expect others to do it, especially if they have no reason to be invested in PHP (how is that reasonable?) (E) you could never get the fixes and cleanups published because of all the existing code which would be broken, unless PHP adopted a risky, even more labor-intensive backward-incompatible renovation project (F) there are already multiple well developed alternatives which do not have these problems, so why would I wait for PHP to get its house in order?

I'm not saying that PHP sucks and could never be fixed.

I'm saying that PHP doesn't have enough positives to justify the huge time and effort to fix it... or to suffer through using it for years. There is no third choice.

Why on Earth would I bust my butt trying to fix this pile of bugs when I can just use anything else?

Just because I feel sentimental about the name 'PHP'?

This is a slowly sinking ship, it is not responsible to tell newbies to get on it.

I agree. I was commenting on Facebook "the social network" and not Facebook the "technology".. :) Anything that can be made to support such large transactions (be it with duct tape and glue) has to have a core capability to support such usage.

It is important to keep in mind that Facebook isn't just a single PHP code base, and thus one can't really make many assumptions about how well PHP is suited to solving certain problems because one doesn't necessarily know about which bits are implemented in PHP, or whether PHP is just a templating/rendering stage over work done elsewhere.

Some other languages might allow you to do certain operations in the front-end more easily, but the way to approach it when using PHP might be to delegate that to a back-end service in another language. Similarly, some languages might allow you to write both most front-end and most back-end software in the same language, where PHP might be wholly unsuitable or makes certain things harder to achieve than it is worth using it for (maybe strict memory usage control, maybe where you're looking for CPU cache wins).

In all fairness with enough hardware you could serve ~1 billion users using virtually any language which supports development of web applications. Just because you can develop a hugely successful system using a language doesn't prove (or disprove) that said language is necessarily the best tool for the job. It just happens to be what FB picked.

Right, you could use BASIC or any Turing-complete language.

Actually, BASIC has been written so many times that you would probably get a pretty sane and systematic experience out of a web BASIC. Relatively speaking.

Didn't facebook largely reimplement php, though?

The question is whether someone is saying that you can't use the PHP language/architecture to create a large and large-scale application like the Facebook front-end, or whether they mean the PHP runtime is unable to perform effectively at scale.

The Facebook front-end code is largely just the PHP language (modulo things like XHP) and follows the shared-nothing, request-based architecture that people who program in PHP expect. With the right abstractions and code organisation, it is fairly clean and understandable even at the relatively large size (even if I'm not generally a fan of the language and would almost certainly not make the decision to use it today).

It is somewhat less interesting whether the PHP runtime is as efficient as it can be. Partly because one can use an alternative runtime like HipHop for PHP if you want to. And partly because very few people have to worry quite as much about performance/efficiency that comes with a large capital/operational cost where you have hundreds of servers.

So while "But Facebook uses PHP so it must be good" is not the best argument, neither is fighting it with "But Facebook reimplemented it!".

It would be better to say Facebook begrudgingly uses PHP due to not wanting to do a major rewrite.

I disagree completely.

This is example of the PHP team working to fix a common criticism of their language: that it's full of inconsistencies. And when encountering push-back from users who depend on those inconsistencies, the developers have stuck to their guns.

Well played to Rasmus.


"PHP is full of inconsistencies! What a terrible, amateur language!"

fixes inconsistencies

"PHP broke their functions! What a terrible, amateur language!"

Haters gonna hate.

i think you miss the larger point... any half way decent developer would never have this issue - breaking changes happen on every platform - or you should assume they will. use encapsulation properly (i.e. actually encapsulate, not just use a keyword meaning 'class' in the OO sense) and problems like this require single line of code changes to fix.

even if you have them scattered across your code base what you then do is realise that you have failed to encapsulate a platform dependency, then encapsulate it, then fix. even on multi-million line code bases this will not take a month. inexperienced programmers are terrible at estimating tasks like this, which often take less time than you think, and less time than it feels has passed as you are doing them.

php is a fine language - the various arguments i've heard against it boil down to "i'm to shit of a programmer to do my job", either by choosing the wrong technology or not being able to just suck it up and get on with making stuff work.

> even if you have them scattered across your code base what you then do is realise that you have failed to encapsulate a platform dependency

Take this line of reasoning far enough, and you're saying wrap every PHP function in your own function, so your programmers program in your synonym language instead of PHP, something like CoffeeScript vs JavaScript, perhaps.

I don't think using PHP (or any language) directly means you're a "shit programmer".

I think the care Python has taken between 2.x and 3.x is a better example of the type of care and concern and community awareness building around this exact sort of change that a language's benevolent dictators (Larry, Rasmus, Guido) should take when altering the philosophy of how the language should behave.

> wrap every PHP function in your own function

That's what I did or tried to do when working with PHP. At least on sensitive parts (date, string, database functions).

Hrm... if you don't trust your core to that extent... then why use it?


"Perhaps it isn't about being paid, but about taking pride in the work you do."

Even if you take pride in what you do you expect to be treated with a certain level of respect. ( Not that being paid means you should be disrespected of course. )

The behavior was deprecated with a warning for how many versions?

>Here's how I read it: We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code

Really? You read it wrong. It is "he have a public API that had a bug --that only surfaced when using it in a brain damaged way, anyway-- and we fixed it along with doing several DRY improvements to our code base. We also gave ample time of advance warning with our beta releases".

"so if it breaks your stuff then tough shit because we're a bunch of amateurs."

An ad-hominem? And its Rasmus that cones out as a little child, to your "mature" reading of the situation? Priceless.

>I especially liked this quote: "Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure." Perhaps it isn't about being paid, but about taking pride in the work you do.

That includes fixing bugs and brain damaged edge cases of the public API.

The complainer and your reading are so off the mark, I can't even begin to comprehend such attitudes exist...

Gotta love Rasmus. He makes me proud to be danish :D

I understand that the bug reporter is in a bad situation but this is definitely an edge case and passing an empty or whatever non-numeric string to a function that is clearly meant for formatting numbers doesn't really seem like good style. is_numeric(), is_float() and casts are available for a reason. So I guess the answer is ultimately 'deal with it'.

That said, I don't see this taking 'months' either, they could just write a wrapper function that mimics the old behaviour and their tests should cover it. If their quality control or inner workflows make changes like this take months, I'd expect that upgrading to a new PHP version and the related testing and QA should take them years.

A wrapper function is absolutely the right way. Instead, he decides to modify the PHP source and recompile it, effectively forcing him to maintain a fork of PHP, as if somehow that magically takes less effort to develop and QA resources to maintain. Wow.

Spot on. He doesn't want to update his 50+ applications, but he wants to patch PHP and deal with the deployment of that to all the servers that support those 50+ applications. And he admits that he's not a C++ coder.

Sounds like a change management nightmare.

But it's only one change.+

+ Technically true. The scope will be equivalent to 50+ change tickets. And he'll be able to blame someone else for any issues that result.

Just goes to show that the issue had become personal, not technical. The complainer was bent on showing Rasmus that his code was wrong (by implementing the change himself), not on fixing the problem in the easiest way.

"Instead, he decides to modify the PHP source and recompile it, effectively forcing him to maintain a fork of PHP, as if somehow that magically takes less effort to develop and QA resources to maintain."

hehe, exactly the same sort of mentality that lead the person/team to somehow write code that end up depending on obscure parts of the api!

It's also really bad style for TAX Software. He should be sanity checking all his numeric data, wow.

On another site, I would say “TRWTF is using PHP for taxes”. For that, give me a language with very strict numeric types!


I'm the first to walk away from a PHP bash session, but a wise man once said, "the right tool for the right job."

this is a classic example of "you mess with the bull, you get the horns."

Headline of this post is totally false and this is not even a bug in PHP, it's clearly a bug in the poster's code, so Rasmus response is right. If you actually try doing this in PHP you get this:

   print number_format("",0);

   Warning: number_format() expects parameter 1 to be 
   double, string given in Command line code on line 1
So the poster willfully ignored the warning. You can fix this simply by casting the first arg as a numeric type:

   print number_format((int)"",0);
Please, if you're this bad at programming and you willfully ignore warnings, don't file bugs, and please do not take a programming job at some place that does important things like air traffic control, banking, or life support systems.

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


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.

Upvoting, because the issue at hand is so old that I find it funny people will use this as a reason as to why "PHP sucks".

For the record, the version in question was 5.3.1 vs 5.1.6, two releases away and three years apart. Of course you'll need to test updates to your app with such version changes. Yes, using semver means this is a minor version release, but if we do that, I'll be first to note the lovely hash syntax changes in Ruby 1.9.

In any case, the current release is 5.4.4.

Sorry I couldn't grok what your opinion on semver was.

Ruby 1.9 introduced new hash syntax but did NOT break the existing syntax one so it was a minor version release (backwards compatible).

PHP made an backwards incompatible change in their code so it should have been a major version increase.

So as far as I can see Ruby is in the right and PHP is in the wrong with regards to adhering to semver.

Is that not your opinion?

Somewhere around Ruby 1.8.6, the stdlib Digest::MD5 syntax changed without any explanation that I know.

In one patchlevel of 1.8.6, they've added a check against creating new Ruby objects while the GC is running (I hope I remember this right), breaking all SWIG extensions at once.

Ruby 1.8.7 changed the C extension API, I think? I'm not sure if 1.8.7 broke the old one or if 1.9 did.

Ruby 1.9 broke "when 5:" in case statements. Files also started needing "# Coding: UTF-8" comments. And then there are subtle changes that probably aren't even documented, like [Math.sin 0] not being valid syntax anymore. Block variable scoping and automatic splitting into Arrays is different.

Ruby 1.9.2 (!) changed the way require() works and added require_relative() which is impossible to properly backport.

And Ruby 1.9.3 fixed a parser bug again, breaking code that worked on 1.9.2. (I think you could have a superfluous "do" in one place.)

Those are the breaking changes that I can remember from first-hand experience now, only the last one is second-hand over IRC. And this is excluding Rake, Rubygems and all the other crap that breaks at every other git commit.

Ruby is a bad example.

I used it as the example simply because it is normally a language that is touted quite superior to PHP. I think it is better in some regards - building/using Ruby DSLs is awesome - but not all.

Languages are subject to bugs. If they didn't have bugs, people wouldn't complain.

I just wanted to reinforce that Ruby and PHP are equally unstable languages. Most changes in my list aren't bugs at all, just obscure design decisions. Even the new Hash literals are likely complicit in breaking the "when X:" syntax that I'd heavily relied on.

The bigger question is probably whether Ruby is any safer from this now, thanks to the ISO (ANSI?) standard.

None of the decisions listed here were "obscure" design decisions and none of your examples indicates that ruby is unstable.

Specifying the source encoding in 1.9 is only required if you have string literals in your code that are not in the default encoding. That should be a rather rare case, in fact pretty much none of my code files has the encoding header. Ruby 1.8 was not encoding aware, so Strings were just pure byte streams and the encoding didn't matter.

Changing the way require works fixed a potential attack against ruby scripts. Effectively the only thing that was changed was that from that point on the working directory was not included in the loadpath any more. Calling `ruby -I . <script>` reverts to the previous behavior. Backporting require_relative is not a sensible decision, 1.8 has reached EOL. If you need to write code that compatible to both ruby versions, just don't use it. It's nothing but a convenience method (in fact, most libraries just use a proper LOAD_PATH setup and don't use it). Since 1.9.2 was the first stable release of the 1.9. branch it's fair enough at that point.

Breaking the extension API between 1.8 and 1.9 is fair enough as well since Ruby 1.9 is a new major release. Ruby's versioning works different than PHPs. A minor PHP release (5.3.1 -> 5.3.2) would be a patch release in ruby (1.9.3-p0 -> 1.9.3-p125). Breaking changes are required at some point. 1.9 added more breaking changes, such as String not being enumerable any more etc. Most of those were required to add encoding support, which was the big and important feature added at that time.

All in all I must say that the only large-scale breakage of existing code I've witnessed in the ruby world was the 1.8 -> 1.9 transition.

So you dismiss a bunch of valid breaking changes because you weren't affected by them and then cite one you know about.

Well played, sir.

Well no, all I'm saying is that they indeed were breaking changes, but not "obscure design decisions".

All of them were made for a reason and the reasons were public. Some of them had easy workarounds (like a commandline switch) Most of them happened at the transition of a major release and made the introduction of major features possible. Ruby 1.8.6/7 was supported for years after the transition for people that had code that's hard to change or adapt. Hey, one of the examples the OP posted is "we had code relying on an obvious parser bug, and it breaks since they fixed it." So well, call it "dismiss" if you want. I call it "evolving a language"

I've been working with ruby at the point when 1.8 moved to 1.9 and it was quite a change. Pretty much every library that handled strings broke, but I don't see any way around that and still get encoding support. Many people actually forget that ruby 1.9 is actually what should have become 2.0.

I've been affected and patched several libs to work properly with 1.9.[1] There's absolutely no reason to become snarky.

[1] most of the changes required were trivial, still it's breaking and annoying.

Fair enough, I apologize for the snark, but then everything you've said hinges on your interpretation of the word "obscure".

Looking at the sibling comment, I'll happily take back the word "obscure" if it sounds too negative and subjective. But I stand by my opinion that Ruby is unstable because most of the above changes could have been handled in a backwards compatible way (for non-pathological cases). That should-be 2.0 was turned into 1.9 does not help :)

Not that stability is always the right choice, I wish C++0x would have been more radical, for example. It does matter for long-lived codebases though.

Well, 1.9 was the "unstable" branch leading up to 2.0, that's why that actually matters. And that's why most of those changes were made at that point - they were intended to land in 2.0. Later the decision was made to roll 1.9 as a stable release since 2.0 would take another couple of years and encoding support was an important feature that people wanted to ship. So a lot of changes that could not be handled in a BW-Compatible way landed in 1.9 since encoding support required those changes. String all of sudden was not enumerable any more since there was now String#each_byte and String#each_char which did something different. Require was changed because loadable encodings were an attack vector, ... But for people that needed the old behavior 1.8 was supported until lately and REE (1.8 patched) is still supported.

The breakage in 1.8.6/1.8.7 was widely regarded as a massive failure on the maintainer side - a bugfix for a security vulnerability that had other changes land in the release (and subsequently segfaulted, sigh). That's however not a design change. Something like that has never happened ever since.

I actually agree with you up to a certain point: The ruby ecosystem is was and still is pretty unstable. Things have settled a little lately, but gems still appear and disappear, are superseeded by newer versions or other gems that do things differently. That's good in some ways, since stuff evolves and improves, bad in other ways - the lib you depend on just disappears or falls out of maintenance. However, none of this is the core-languages fault. Behavior of ruby as a language has been pretty stable during the last couple of years.

Hahaha. People wouldn't complain. That's a knee slapper.

No more preposterous than software without bugs.

At that point I'd start making fun of your username ;)

Yep, all those are true, I wasn't thinking. I was just focused on the hash syntax statement, thank you for all the good examples.

The following does not work anymore in 1.9 (at least when it was released, who knows if they reverted the change):

    {"a", "b"}
And there were plenty of gems and small scripts online I was able to get working just fine under 1.8.7 but not 1.9. Thankfully that is largely no longer the case, as things have been updated or replaced.

String class was also given a nice kick in the ass, at least in regards to iteration.

Would you say that these were not backwards incompatible changes? Code that worked before stopped working. Breaks BC in my book. And in both cases the changes were arguably for the better.

- Stop writing code with uninitialized variables - Stop iterating over stuff that shouldn't be iterated over in that way

As far as why the changes were thus, it was decided to destroy PHP 6 - do people still write books about that? - and port every change other than unicode support down to 5.x. Someone feel free to correct me on that point.

It doesn't work in the latest 1.9 either. It was a bizarre syntax that hardly anyone used from my experience (I've been a library-oriented Rubyist for several years and never saw it in production code.)

However, String is a good point, and especially around character encodings. Not to mention threads, major stdlib changes, enumerators, and more..

I don't "really mind" if it breaks totally (i.e. throws an appropriate exception or doesn't parse the syntax check).

I find it much more irritating when the behaviour subtly changes and introduces edge cases that may not be picked up in testing / normal usage.

Passing in an empty string to a function that states it takes float as it's argument is certainly an edge case the developer should have thought of.

The again, in PHP, interpreting strings as floats is not unusual and pretty well defined. So in PHP it's also a case the developer could have considered normal in his expectation that PHP would behave as usual (and it did, prior to 5.3, for this precise function)

Not for user-provided input. That's just a dumb thing to do in any language.

Probably. But then again, we're talking about a language where THIS happens:

php> echo "2coolforschool" + 1;


php> echo "2.1coolforschool" + 1;


php> echo "coolforschool" + 1;


So treating all kinds of garbage as valid numbers is absolutely part of PHP.

That's just the general design philosophy of the MP components of the LAMP stack.

Do the stupidest thing that could possibly work; and it probably will. For now.

> Not for user-provided input.

Not what for user-provided input? The source of a string does not matter to this rule of PHP: a string used in numeric context will be parsed and converted, if it can not be parsed as a number its numeric value will be 0. That's it. That's how the language defines strings in numeric contexts.

> That's just a dumb thing to do in any language.

Sure, you won't get any argument from me on that, but that remains how PHP works and has always worked.

It doesn't matter anyway. Semver is just a practice and not one everyone has or must sign up to, especially in its official form.

Further, you're right about Ruby 1.9's hash syntax, although in the interests of accuracy, it's more accurate to consider it an additional syntax. It certainly doesn't replace the existing one (indeed, hashes notated in the new style get returned in the old style with #inspect) and I don't believe there are plans to ever remove the standard syntax.

Why would you expect PHP releases to adhere to rules that some guy threw together? Especially considering PHP has about a decade of history using the numbering scheme they do use.

Neither Ruby nor, as far as I know, PHP follow semver. Historically all bets have been off when it comes to breaking changes on "minor" releases.

are people really looking to this as a reason why php sucks? i thought the point of the post was to mock the "bug" reporter and his clueless sense of entitlement.

> After carefully reviewing this bug report with our board of directors on 4chan, we have come to the conclusion that your "rusty C skills" should be enough to fix the issue.

I am sad I was not invited :(

You should escalate that up at 4Chan!

So the options are:

  1. Change thousands of lines of code (probably `sed`-able)
  2. Patch PHP to re-introduce the original bug/feature
  3. Downgrade PHP back to the version that had the
     bug/feature you were relying on
Why is option 3 not considered in this thread? It was working before, and evidently they can control the version of PHP (since they can patch it). If upgrade breaks X, and you rely on X, don't upgrade. If you need to upgrade for Y, do so, and fix X. That's just how such things work.

Problem 1: The old versions do not get security patches. For example, entering the number 2.2250738585072011e-308 hangs the interpreter in old versions, as far as I know this is unpatched in PHP <=5.1. This allows a very effective denial of service.

Problem 2: You are delaying the unevitable; it's nice to use new features of the language, having to code in old versions is a pain for developers. Small continuous upgrades are easier to handle than rare gigantic ones.

Small continuous upgrades without ever changing your code is the same cost as a gigantic one without ever changing your code - they either work, or they don't, in variously subtle or spectacular ways. The tipping point lies at some changeset, you just need to hit it.

You upgrade, you may need to change things. It's just a fact of life. Or, you pick a library / language / framework / everything that guarantees 100% backwards compatibility as documented, that never has bugs (since fixing those breaks 100% backwards compatibility), and you never use features in even remotely-unexpected ways. Like in this case.

This is why having a good suite of unit tests is so important.

3) He said they changed hosts and very few hosts offer old versions of PHP.

I don't know if that's correct, but that's what was used as an excuse.

Ah, I must have missed that part, thanks. Though changing hosts is equivalent-enough to upgrading software that I think the point still stands. They probably changed hosts to save money - either go back, or fix what the changes broke, it's part of the standard expectations of changing things.

edit: actually... no, that still doesn't work. They clearly have 100% control over the interpreter since they can patch the source and use the patched version.

"This is going to cause us MONTHS (to fix)". Whether he is right or wrong, you cannot say he's not over-exaggerating and being a pain in the ass. Also, expecting "" to == 0, when it's easier and proper to enter 0 just doesnt make sense. That's like saying "i expected your software to make up for me not using it correctly". Sass or not from the guy who wrote PHP, this guy is just a pain in the ass and his complaint is ridiculous.

ADDITION: As the creator stated, it's been issuing warnings for some time now and was changed LAST YEAR. there's just no foundation to this complaint.

People have been wondering "what would Linus have said?" I'm pretty sure he wouldn't have broken the existing (undocumented) behavior in the first place "because it breaks applications and the one and only reason for kernel is to allow applications to run". But then again, PHP is not a kernel. :)

I think you are entirely right. As Linux says "Kernel exists for its users". Pretty similarly, a platform (php/zend) exists for its applications.

Linus has always been pretty adamant about not breaking API behaviour even undocumented ones. But in this case, undefined behaviour had been previously documented.

Also, was it him or Ulrich Drepper who were against changing memcpy undocumented behaviour. (mempcy used to work with overlapping regions too.)

PS. This mailing thread is from 2010. It's really old.

Ulrich Drepper was vigorously in favour of it. If your application breaks, it's because it was written wrong.

Exactly. The only reason this bug got to production, is because the function accepted an empty string parameter in the first place.

Yes, eg: https://lwn.net/Articles/494993/

Linus took extra steps to no break autofs behavior, even though it was (more) due to a bug in GCC than anything else.

The "is there anyone you can escalate this too" reminds me of a PERL newsgroup thread I saw where someone tried to rip Larry Wall a new one, asking (in a condescending way) him if he knew anything about PERL.

Or the time I suggested on HN that cperciva use scrypt (not noticing the username on the comment).

Haha, if you could find that again I'd like to see it!

To standardize PHP code is good, let's be clear... There's a lot of "misbehaves" in PHP. And if you're not casting or checking all the time you can get a wrong result, without even knowing. At least now/then (it's an old topic) number_format WILL tell you that you're not formatting a number and that's GOOD.

To standardize PHP is to create a new language not named PHP.

If you read it until the end you will find out that the technical support representative talking to the irate customer is the creator of PHP. As the creator, PHP can be whatever he decides he wants it to be.

And he has decided it is not a standardized language, by any stretch of the imagination. That's the guy's point, and it's spot-on.

As an aside, I didn't realize there would be people on HN who wouldn't recognize rasmus@php.net immediately.

While there are some industry veterans here, there are also a good amount of CS students and other beginners. I myself didn't know who he was until I got to the end of the article.

PHP can be whatever he decides he wants it to be

What you're describing is whimsical, not standardized.

So what exactly is the point of PHP then? If you want to write Java, write Java.

If PHP has any place in the world at all, it's as a language for the web with a minimum of extraneous boilerplate. If it fails at that goal, well, wtf? If you're going to be all proper about things, why not just do it in Python or some other sane language?

I have to agree with the bug submitter in concept, if not in attitude. PHP is a dynamically typed language. As such, methods should expect surprises about the types of data received. Seriously, I've had PHP treat the same input as a string one time, an interface another, it's like it uses whatever is convenient at the time. If you neeeeed that data to be an int, cast it as an int, don't punish the user because type system chose a different type this time.

Additionally, and more to the point, in PHP 0 == "" == null == false, so it shouldn't be unreasonable to expect them to be treated as equivalent. It's also a nice thing when a method can always be trusted to return the same type, or these types of issues can end up cascading.

In any case, 'should' and 'nice' things are hard to rely on in PHP, that's why you should always have the docs open and read everything when writing PHP, making even basic assumptions about a method being well behaved will likely screw you over. :)

Especially for a novice, formatting a field on a web form into a number, and seeing PHP format an empty field as zero, so you can carry on with your math, makes sense. "Oh, web parsing language, sees empty number field as zero, great!"

Principle of least surprise "for the novice web developer" says empty string to zero makes sense in this case.

Meanwhile, empty string with zero decimal places returning null would be less surprising to a pro, but in PHP, the first behavior would also be unsurprising to a pro.

So developers complain that PHP is not standardised, but when it is in a major version upgrade developers complain that it's becoming standardised?

Are you somehow under the impression that developers are the Borg? Different developers can have different opinions on what PHP should be.

A lot of the time, it's developers who don't use PHP who complain its not standardised, and developers who do use PHP who complain when it does change! To be contrary, I'm a PHP developer who likes the on-going standardisation, but didn't really find it too big a problem the existing way. YMMV.

Having number_format in so many thousands of places across so many products is indicative of pretty poor code. If you have bad code, you can hardly expect to be able to upgrade to new versions of the language seamlessly.

Speaking of which, are they going to upgrade to 5.3 without testing all those thousands of places across all their products?

How is that indicative of bad code? That seems like a very big jump to make. If you're using PHP at the presentation layer you are probably doing a lot of this. Why would you write some sort of abstraction around number formatting when there is an abstract function to just do it for you?

This is particularly true if your applications are older and written before modern template systems made it a bit easier to abstract these concepts to filters and the like.

I'm just saying it's a sign, or a smell.

Just as you say older/pre-modern -- bad code or not, the same caveat applies about upgrading core language platforms. Even a strictly typed language with a much more standardized API like Java can be hard to upgrade major versions (where I would consider 5.3 a new major version).

It's bad code alright. But I would argue that any code you write in a bad language turns into bad code, no matter how you do it. It might be good enough for your application, so that's fine. But it would be bad nonetheless. And PHP is not a sane language by any measure. So here we have a bad code author dealing with it's bad languague's shortcomings and expecting that they be solved by the very people who created said bad language in the first place. Quite entertaining.

I am mostly on the side of the bug reporter here. PHP changed the behaviour of a simple method that has been there since PHP4 (which is oooold).

It returned 0 previously for "", why change it now? Was "" == 0 a bug ?

A) The new behaviour makes more sense.

B) The change was discovered as a difference in behaviour in two major releases that were three years apart.

C) Rasmus Lerdorf can change PHP however he wants. It is precisely because of this that PHP has been so {'widely success', 'pain'}ful.

D) The reporter was being overly dramatic regarding the change going to take a supposedly crazy amount of time to fix.

E) You don't pass a string into a function that's usually returning a string without at least casting to a string when part of its intended behaviour is at times not returning a string. Casting in this case even before the function even changed would have been an exceedingly good idea.

F) (edit) I vote we burn in hell PHP developers who tack on comments to a long closed bug report to offer their opinions like joezimjs did. Especially when they display a basic ignorance in saying crap like "NULL is neither a string nor a number."

I disagree with point A. The old behavior makes a LOT more sense symbolically.

I tell you that you have no apples. Write the number of apples you have on a piece of paper. What did you write? I bet it was 0, not some arbitrary, non-writable symbol for an abstract concept that could mean "nothing" or "error" or "empty" or ..

I don't agree with your analogy. The question is more similar to "Can you please tell me the number format of <silence>".

How can the answer to an unfinished question be "0"? 0 is an actual valid answer, when people are asking for number_format(0, 0).

In this case, NULL is definitely more appropriate, because the input is invalid.

Of course, in a more sane language, it would throw an exception, rather than silently returning a wrong value.

> he question is more similar to "Can you please tell me the number format of <silence>".

Well in PHP, the number for <silence> is 0, so it would stand to reason that the formatted number for <silence> is 0 as well.

What's the numeric representation of the volume of <silence>? 0 dB

Since dB are a log scale, more properly, it would be -Inf dB.

0 dB = atmospheric pressure. -Inf dB = vacuum of space.

So you make up a different question to fit the answer you want? Actually that seems about right for PHP.

I think you missed the point here. Steve's analogy asks for a number format, not a volume...

Downvoted for cleverness.

I agree with Steve. "No apples" actually is "0 apples".

Your analogy is a misunderstanding of null. Null is like you asking me how many apples Joe has. I say I don't know. If you write down 0, I'm going to stop you and say, "I didn't say zero, I said I don't know."

BOTH behaviors don't make sense. The right behavior is to throw an exception.

Absolutely agree, and that's PHP's biggest issue. It is constantly doing things like this instead of simply complaining and stopping things down like any sane system would.

If I were in charge of PHP, release 6 would be 5.4.4 with the standard library happily throwing exceptions on invalid input. That's it. The language would be 100% more useful instantly.

As mentioned to parent: then you'd have a lot of work to do to clean up one even more widely used language : )

You mean JavaScript, right? Reading this conversation I was wondering how no comment would point at the same or bigger similar issues in JavaScript.

This depends on language. Or you'd have to dismiss at least on widely used systems programming language as well. : )

Well...if we are allowed to change language completely we could change to a type safe language (as most systems programming are) and we wouldn't have this discussion in the first place since it would be impossible to call the function with a string parameter...

I tell you that you have "foo" apples. Write the number of apples you have on a piece of paper. What did you write?

I tell you you have 12/0 apples. Write the number of apples you have on a piece of paper. Some "functions" are not defined for all inputs. Better to give a "that doesn't make sense" answer than a bogus answer.

I work on systems where D) is perfectly reasonable. Where one "small" change results in a hell of a lot of regression testing and doc changes.

What I don't get is that they are keen to modify php source. But not to just keep using the same php release?

I agree with E, they take floats not strings apparently.

Maybe there are other guidelines (Security related, no maintenance for the old release) that were 'forcing' them to update.

I guarantee that security guidelines were not involved in any decision about which version of PHP to use in a project. All PHP code is security tainted and needs protection at the underlying data service layer.

I would almost guarantee security guidelines were the reason. He states they are dealing with tax data, and I would bet they handle some credit card data as well. If they even touch credit card data they have to be PCI compliant (http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...) which requires specific versions of PHP.

If it requires specific versions of PHP, I would hope that doesn't include a self-patched build that deliberately masks erroneous input data by treating NULL as 0

The moment you run a patched build, you're IMHO not running the officially sanctioned version any more.

Reporter posted this: "...which is why we are moving to a supported, fairly-recent platform". I'm guessing it's the support their after.

I disagree with (A).

According to the php docs

floatval('122.34343The') == 122.34343

floatval('BLARTLBARTFAST') == 0

Why should it take the input and choose a different response than what floatval would respond with?

If floatval returns null on 'BLARTLBARTFAST' and '122.34343The' then this function should return null. If floatval returns 0 (or whatever) than this function should return the same.

It's inconsistent behavior.

> I disagree with (A).

Since you quite clearly have no idea what function we're even talking about or what it's supposed to do, I will just point you to the documentation rather than more explicitly explain on how many levels you are wrong: http://www.php.net/manual/en/function.number-format.php

Pointing to the documentation does not work in this case. The documentation shows the user was not sticking to the function specs, yes, but neither does PHP most of the time. If PHP were a consistent (serious) language, I might see your point. It's not: it generally aims for leniency and minimum (well, small) surprise but doesn't seem to be doing it this time. I think you should make your argument clear.

I don't believe there should be any obligation for developers to maintain undefined behavior across versions. Even with defined behavior, sometimes APIs change, for legitimate reasons.

The function requires a float, and the developer is passing in an empty string. To rely on this type of edge-case behavior is ridiculous, in my opinion.

Regardless of the prior behavior, that particular behavior was not documented [1] and subject to change. I do think it is PHP's (very big) fault that the proper documentation on various edge cases is missing, but it is a bit too much to disallow PHP to change undocumented behaviors. That said, the proper documentation is not enough (and PHP does not get this right either); it's rather a mere prerequisite.

[1] http://php.net/number-format says the first argument expects float, and does not say what happens if it receives non-floats.

The specific usecase the bug reporter has provided DOES raise a warning, which he has intentionally routed to /dev/null

php -r 'print number_format("",0) . "\n";'

PHP Warning: number_format() expects parameter 1 to be double, string given in Command line code on line 1

Well, exactly. It doesn't say what happens, so pass floats or expect the unexpected. I get your point but I don't think I have ever seen documentation anywhere that covers all of the possible 'abuse' scenarios.

It is possible to add a catch-all clause to the documentation. For example any non-float argument is converted to float via floatval(), or raises an error, and so on. This behavior can be made consistent across every API so that the documentation has only one place to describe it. PHP is missing this either AFAIK.

> This behavior can be made consistent across every API so that the documentation has only one place to describe it.

Sounds like that's what 'zend_parse_parameters' does, actually.

I agree this would be ideal. Will definitely keep this in mind when writing documentation (and code) for my own tiny open source projects. All the double and triple checking just adds so much bloat most of the time...

Documentation is hard, thats why most of it is open source. Pretty sure you can edit the php docs online if you so chose.

> Find the dependencies —and eliminate them

Excel team motto.[1]

While I understand Rasmus' response is legitimate, I also see that depending on something as crucial as a programming language implementation is less of a good idea than it might seem at first. Makes things like Maru (the programming language[2], not the cat) much more appealing: if there's something you don't like in your compiler, at least you stand a chance at fixing it (Maru is less than 2K lines, and counting down).

[1]: http://www.joelonsoftware.com/articles/fog0000000007.html

[2]: http://piumarta.com/software/maru/

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

Considering the filer of the report goes on to say this, at what point did they fail to realise that moving from an "old PHP 5.1.6 Solaris 8 box" to an "RHEL5 with 5.3.1" should have required the same level of testing and signing off?

No sympathy for a developer who completely changes their environment (OS, PHP version, at the very least) and then bitches about stuff they failed to anticipate not working. This is not a reflection on PHP, for once.

I think the guy wasn't thinking the situation through entirely, but someone of (relative respect I suppose, creator of PHP is still the creator of something widely used) respect shouldn't be acting like this. It's always a shame to see people who have promise and talent show how childish they CAN act. Having his underling (someone who works on his language of no known note) make a smartassed response was in turn also pointless and negative whether he requested/urged it passively or not.

Related article about the same bug report: "When does a bug turn into a feature?"


Way to jump onto a thread that hadn't had any comments in 10-month-old joezimjs and add pretty much zero to the conversation.

It was really to read that conversation. I do not care whether it was a good or bad decision to make those changes in PHP but you simply can not talk like that to a person who has put thousands of hours of unpaid work (while he could get a fat pay check easily) and you are making living because of what he has done. It's just immature.

This is pretty standard with large production software. You often see grids in the documentation, e.g. this version of the app server is only certified for these brands and versions of Java. Even if you have a paid support contract with us, do not contact us re using it on something else. So in the reporter's case, their software just isn't certified for the new version until updated. No big deal.

I remember working at a company where the servers were Ubuntu, the auto-update mechanism replaced Sun Java with OpenJDK which broke countless apps and web servers, like the Concur app, the build system, etc.. God that was a nightmare. A real setup like at bigger companies I've worked at would have tested that update on developer boxes, integration boxes, testing and training boxes, and only then sent it to production.

This reminds me of http://news.ycombinator.com/item?id=3860361. Ignoring something that needs to be fixed because it might break workarounds is a lot to expect, and it likely why the IEs stayed broken for so long.

Uh, so let me get this straight. They are using number_format, which according to the documentation takes a number and formats as a string, and giving it a string as the input parameter?

They were never using the function correctly in the first place! Not sure what they have to complain about here...

In April 2010 Rasmus Lerdorf joined WePay (a YC startup) in a senior position.


He's always been like this, best I can tell.

Everybody was in the wrong here. The developer should've written better code. I'm a PHP developer and I've learned that if the input is that important, I need to cast it. I've used C++, C#, and Java and I like strict typing. If your application is that sensitive then maybe it should've casted the input to ensure the output is consistent.

As for Rasmus, I think he could've explained why it's a "won't fix" type bug in a slightly more diplomatic fashion, though I can't say I would've handled it any differently. He's completely right as to why the behavior shouldn't change. Finally, bjori's response was completely unnecessary, inflammatory, and downright rude.

This has shown me the worst of the PHP community. I'm not ashamed, just more wary.

This is exactly how I feel about it.

I think it's an example of how not to interact in a community, from both angles. Also, I can't stand the notion that open source developers are "volunteering" their effort. All programming is voluntary in the sense that you are making a free choice to do it and most likely gaining capital (social or financial) in the process. I voluntarily build software and give or sell it to others all the time.

Issue here is not whether it can be fixed, anything can be fixed. Issue here is why in the world they have changed things in a such way to break the old code?! Was it necessary? I don't think so... I understand the need to re-factor, and making some old stuff obsolete along the way, of course, but it's not the case here. It's just that someone wasn't really playing attention to this. And this type of negligence to the details is really killing php as language. If after 10+ years in php I need to re-read the manual every now and then to make sure if the things are still working like the last time, it's just crazy..

Blaming your problems on the person making something you are consuming is always a useless endeavor. Make a function if you are using something in hundreds of places that relies on user input. Not terribly difficult.

| ^ 0 isn't some magic all-encompassing number. It means 0. NULL means no number based on your shitty incorrect input, and is the correct choice.

Best response to the whole thing except for Rasmus' awesomeness.

"Please escalate this to someone who can answer the question as to why this was changed. If no one knows, then why was default behavior changed?"

Mr.Rasmus, respect, for not ending the thread at this statement.

In this kind of situation where there's a bug or limitation or some kind of issue with a language function we usually create a wrapper to handle the whatever rules we have internally within the company. In this case the empty string that is supposed to be NULL should be handled within that wrapper function. One function to modify instead of several places in the application.

You can't win, people on one side want this weird behaviour made backwards compatible whereas people complain that the language has a large amount of weird edge cases and should be better standardised around more sane expected values.

In this case they were standardising parameter parsing code, which I think is definitely the direction you want to head.

PHP is doing the right thing here. Way back when I first tried PHP out, I tried joining strngs together with a + operator.

I made a mistake, but I kept getting back zeros instead of some sort of NULL or an exception. This is a bug, in the sense of its not how I wanted PHP to behave. I'm glad PHP is fixing its string-to-numeric bugs.

All the discussion aside, there is so much wrong with it:

First of all, why does the function even accept strings? There should be some eception happening. Second, why does it return 0, i could understand NULL but not 0 (for a function that is supposed to handle numbers, having it return a number in the invalid case, what is that?)

> First of all, why does the function even accept strings?

Why not?

> There should be some eception happening.

PHP's built-in functions do not ever throw exceptions.

> Second, why does it return 0, i could understand NULL but not 0

Well it doesn't anymore, but it used to, and that kind-of made sense in the context of the language being PHP: in PHP (userland), when using a string in a numeric context that string will automatically be converted to a number:

    > php -r 'print (1 + "3") . "\n";'
when the string can not be parsed to a number (meaning it is not prefixed by something which looks like a number), it's just converted to `0`:

    > php -r 'print (1 + "whelp") . "\n";'
And I expect that is the former behavior of the function: it coerced whatever it got to a number, so an empty or non-numeric string would get converted to the float 0.0, which would then get formatted as usual.

Just shows me how broken this language is to the core.

I don't think you got to the real problem here. Weak types are quite useful for some tasks, and of course they are nothing new. Languages that convert between integer and string types automatically are well suited for text processing in general (including generating web pages dynamically).

The problem with PHP's weak typing is PHP's hit-and-miss implementation. Check out AWK, another weakly typed language, for example:

BEGIN{printf "%5.2f\n", ""}

prints "0.00" as would be reasonable.

Not that I disagree, but PHP only got exceptions relatively recently. The built-in functions existed long before that. Without exceptions, the options for error handling are to return an error value or exit, writing an error message somewhere. Null seems like an appropriate error value for "you asked for some data formatted as a string, and for whatever reason, I couldn't provide it".

> why does the function even accept strings

Because PHP was invented as a web language to process web forms and generally your inputs always came to you as a string.

PHP is a dynamically typed language, so although it expects a number, it will accept a string as it will try and parse that string into a number (e.g. you could pass it the string "2.23232" and it will work in the same way as if you pass it 2.23232 as a float). In this particular case, as the empty string can't be parsed into a number, it does indeed throw a PHP warning and treats it as a null input. My understanding is that it used to return 0 and that was considered a bug by some (although others, including the author of the function, decided that as the return type was a number it should ALWAYS return a number). The change that is under "dispute" in this case is that it has indeed been changed to return null, which is what most people now agree is the best way, and is consistent with other PHP functions.

I believe you are refering to strongly vs weakly typed, not statically vs dynamically typed. A strongly typed language would not try to parse the string into a number (although it would indeed accept a string, if it is dynamically typed as well).

I did indeed mean weakly typed (PHP is both dynamically and weakly typed). Haven't had my coffee yet this morning.

It accepts strings because PHP does not support type hinting for scalars.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact