Re: Bug #14538 Updated: dirname fix broke behaviourthat it had since PHP 3

At 03:43 16/12/2001, Manuel Lemos wrote:

So, there why keep giving more reasons to not upgrade?

Because sometimes it's necessary. The way dirname() behaved was buggy and unintended - it simply did not do what it was supposed to do. Perhaps taking it to the extreme - it's kind of like pow(2,2) returning 4.01 instead of 4. If such a bug existed in pow() and we fixed it, we wouldn't have added an ini switch to turn it on/off. register_globals is completely different. register_globals is a concept which turned out to be very problematic, but people who bought into it should be allowed to go on using it. We also have to be a bit realistic every now and then, and realize that the vast majority of PHP code today, and we're talking dozens of millions of lines of code, relies on register_globals being on. That's not true for dirname(). It doesn't mean that BC breaks that only affect a small number of people should be taken lightly - but obviously, this plays a significant role.

Admit it, you were not aware and not even documented the change that Andi made to the behaviour of a function that worked like that for 3 years.

Sure but they way it seems to me is that reporting the problem did not make any difference. So why bother reporting?

It's your decision. Don't expect the dev-team to treat anything you put in the bugs database as the 11th commandment. The dirname() example is relatively unique, because the new behavior is not a problem, but a fixed behavior which causes incompatibility.

I am afraid that a lot of people simply do not bother to report problems, even when it affects their businesses, because they just get this kind of response and they certainly can use the time they spend making a useful report in things that can really result in something that the need.

Don't worry so much. You're the first person to bring up this point in 5 years :) Zeev