Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We will try to stop fixing bugs in PHP

bugs.php.net

Post reply on HN
Print view View original

181–190 of 319 posts

Re: We will try to stop fixing bugs in PHP

#181

Post by Terretta »

buster wrote: post #121

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?)

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

Re: We will try to stop fixing bugs in PHP

#182

Post by lnanek2 »

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.

Re: We will try to stop fixing bugs in PHP

#183

Post by gedrap »

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.

Re: We will try to stop fixing bugs in PHP

#184

Post by robryan »

andreasvc wrote: post #173
robryan wrote: post #154

In the same way that projects enforce a certain subsection of c++, it is probably best in PHP to not code anything in a way that relies on unusual quirks of the language to work. None of my code gets bitten here because I never passed number_format anything but numbers.

In my opinion weak typing is an unusual quirk, but there's no way to get around that. I really wonder kind of reasons could be given to defend it; I don't think a strongly typed language like Python is any harder because of its types.

I tend to agree, these days where possible when working in PHP I try not to rely on PHPs magic type conversions behind the scenes for things like comparisons.

Re: We will try to stop fixing bugs in PHP

#185

Post by masklinn »

rapala wrote: post #155
masklinn wrote: post #107

Earlier quoted context omitted.

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

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

Re: We will try to stop fixing bugs in PHP

#186

Post by DHowett »

snorkel wrote: post #180

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…

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.

Re: We will try to stop fixing bugs in PHP

#187

Post by rbanffy »

kenneth wrote: post #103

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 h…

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.

Re: We will try to stop fixing bugs in PHP

#188

Post by masklinn »

methodin wrote: post #157
masklinn wrote: post #146

Earlier quoted context omitted.

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.

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

Re: We will try to stop fixing bugs in PHP

#189

Post by TylerE »

methodin wrote: post #157
masklinn wrote: post #146

Earlier quoted context omitted.

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;

3

php> echo "2.1coolforschool" + 1;

3.1

php> echo "coolforschool" + 1;

1

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

Re: We will try to stop fixing bugs in PHP

#190

Post by jerf »

pacifika wrote: post #136
kevinalexbrown wrote: post #79

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 c…

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.

Post reply on HN