Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The error message is quite informative, isn't it ?
array_shift() modifies specified variable and "explode('.', 'file.txt')" is definitely not a variable, but an expression.

Hi Tony,

This actually is a defect, the behavior has changed from previous versions of PHP including 4.X and 5.0.X and PHP 5.1 BETA #1 in a non backwards compatability way that will break existing scripts.

The script has worked properly with all versions of PHP since before PHP 4.1, it stands to reason that you should be able to execute scripts that that work with PHP 5.04 in PHP 5.1.

It is interesting that the behavior changed in such a way that it breaks the script in beta 2 where beta 1 and previous works as expected.

Obviously backwards compatability is important for PHP and if it randomly decides to break backwards compatability it will be very difficult to continue to sell in enterprise environments.

It's actually a bug fix that "breaks" this. Where in the manual does it say that you can pass something else than variables by reference?

The problem being that because the behavior was not consistent with the documentation since before PHP 4.1 means that this is a defect in documentation if nothing else.

This has already broken several popular open source PHP applications on my test bed sever and is sure to have a wide impact since it causes a fatal error.

Once a behavior is introduced, even if it is technically wrong it shouldn't be suddenly changed without warning especially when such change introduces fatal errors.

This is a fairly big change in the way that this function works, whether it was documented in that way or not (again seems like a documentation problem not an implementation problem).

The fact that it behaved in the previous way for at least 5 years would indicate it deserves more consideration before it is allowed into the wild where it will break applications and annoy both users and developers.

Professional web development companies such as my own will not like having to go back and "fix" countless websites built on popular platforms because behavior was "fixed" in such a way that it makes a function less usable than it originally was before the fix.

It seems that the time to make such a change would be a major release of PHP such as PHP 6, not PHP 5.1 especially since a good number of PHP 4 users have not yet moved to PHP 5 and may consider PHP 5.1 the first stable release.

You have to consider backwards compatability and breaking compatability that has been there since PHP 4.0.x is a fairly big deal where changing the documentation a little wouldn't be.

The question isn't where is it documented that way the question is why shouldn't you be able to do it? 

It makes since to be able to take the return value from a function call and use it in another function call all languages including PHP allow you to do so in cases where the return value is useful.

Removing this ability not only breaks compatability with both PHP 4.0.x, 4.1, 4.2, 4.3 and 5.0.x but it also makes PHP itself hardware to use in this case and results in bulkier code without need.

Without this fix, you get memory corruptions which cause strange and very hard to reproduce problems in large "enterprise" applications, or actually, even in small ones. It's either this fatal error (and it *should* be fatal, as you're doing *something wrong*), or hard to debug, incomprehensible vague errors in your enterprise scripts. I know what to choose.

I have no problem if you want to make a note in the manual that indicates in the past the function could be used in this form however this form is now deprecated and support for it will be removed in the future.

However that has not been done, there was no note made about the change to the function and the change was done in between beta releases of PHP 5.1 (between 1 and 2).

GCC supports allows uses of functionality in unintended forms even though it isn't pretty because it was initially created in that form.  

They mark it as deprecated for at least a minor release (usually a major x.x release or even just x release for example from 3 to 4 in the case of major changes) and then remove it once the community has had an appropiate amount of time to update their code or choose to stay with an older version.

In the past PHP has followed this type of reasonsing, in attempting to avoid breaking current behavior until a major release because people there is most likely porting that will need to take place at that time anyway.

However introducing fatal errors without a warning with something that has worked for 5 years is simply bad and bogus.

Opened again

This is not a bug, also, if you have anything else to add - only a patch which solves this problem is going to be considered. 

This most certainly is a bug and one the community is now outraged about. 

Opened again, the memory corruption "fix" is simply an ugly solution and should be pulled out of PHP until it can be fixed properly.

It too severly breaks BC of PHP and there is massive community outrage over this "fix" that breaks 60-90% of all PHP scripts including phpMyAdmin among other popular tools.

All this "fix" is doing is preventing users from getting the latest version of PHP, ISPs will not install it because it breaks their users websites, this will expose users to security problems and make it very difficult to get newer versions of PHP installed.

If massive changes needed to be done to fix this that is what should have been done, not a band aid solution that made a problem someone MIGHT encounter into something pretty much everyone encounters.

Just the fact that this problem has been there since early PHP 4 days indicates the exposure and risk is fairly low, one more PHP release with it the way it was isn't going to cause an end to the project while releasing a half baked "fix" that does more harm than good is causing high amounts of negative press and community outrage.

In my opinion this is another example of a few people assuming they know what is best for a community instead of actually listening to the community.

.