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

221–230 of 319 posts

Re: We will try to stop fixing bugs in PHP

#221

Post by gbvb »

j_col wrote: post #218
gbvb wrote: post #206

Earlier quoted context omitted.

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

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.

Re: We will try to stop fixing bugs in PHP

#222

Post by rapala »

masklinn wrote: post #185
rapala wrote: post #155

Earlier quoted context omitted.

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

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.

Re: We will try to stop fixing bugs in PHP

#223

Post by psaintla »

wvenable wrote: post #217
psaintla wrote: post #205

Earlier quoted context omitted.

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

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

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.

Re: We will try to stop fixing bugs in PHP

#224

Post by cube13 »

martenshinwarts wrote: post #201
Draiken wrote: post #169

Earlier quoted context omitted.

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

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

Re: We will try to stop fixing bugs in PHP

#225

Post by wvenable »

psaintla wrote: post #223
wvenable wrote: post #217

Earlier quoted context omitted.

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

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

Submit a ticket.

Re: We will try to stop fixing bugs in PHP

#226

Post by columbo »

gbog wrote: post #208
Terretta wrote: post #177

Earlier quoted context omitted.

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

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

Re: We will try to stop fixing bugs in PHP

#228

Post by jconley »

to3m wrote: post #166
jconley wrote: post #17

Regardless of merit on either side, the attitude presented by the creator of PHP in this post makes PHP and open source in general look bad. Seriously? I still can't believe that's how the situation was handled. EDIT: Rasmus calls the bug reporter an idiot in the first reply. It's probably some sysadmin that has been tasked with upgrading the infrastructure and really has no idea what to do. So rude. It would take ju…

I quite agree. It doesn't cost a thing to behave like a gentleman, and people usually respond well to it. And if they don't, being rude is unlikely to work any better, and could just leave them feeling justifiably resentful. Rudeness is not the winning strategy.

How many downvotes did you get? :) Apparently you get downvoted nowadays for having an unpopular opinion. Strange.

Re: We will try to stop fixing bugs in PHP

#229

Post by Too »

eitland wrote: post #97
Too wrote: post #77

Earlier quoted context omitted.

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

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

Re: We will try to stop fixing bugs in PHP

#230

Post by jiggy2011 »

rbanffy wrote: post #187
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 co…

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.
Post reply on HN