#33495 [Bgs-Opn]: Fatal error: Only variables can be passed by reference with array_shift
ID: 33495 User updated by: jsheets at idahoimageworks dot com Reported By: jsheets at idahoimageworks dot com -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: FreeBSD PHP Version: 5CVS-2005-06-27 (dev) New Comment: 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. Previous Comments: [2005-07-18 21:17:55] [EMAIL PROTECTED] 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. [2005-07-18 20:58:41] jsheets at idahoimageworks dot com Opened again [2005-07-18 20:58:25] jsheets at idahoimageworks dot com 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. [2005-07-18 20:54:27] [EMAIL PROTECTED] 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. [2005-07-18 20:44:58] jsheets at idahoimageworks dot com 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
#33495 [Bgs-Opn]: Fatal error: Only variables can be passed by reference with array_shift
ID: 33495
User updated by: jsheets at idahoimageworks dot com
Reported By: jsheets at idahoimageworks dot com
-Status: Bogus
+Status: Open
Bug Type: Scripting Engine problem
Operating System: FreeBSD
PHP Version: 5CVS-2005-06-27 (dev)
New Comment:
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.
Previous Comments:
[2005-06-28 09:10:37] [EMAIL PROTECTED]
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?
[2005-06-28 01:40:37] jsheets at idahoimageworks dot com
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.
[2005-06-27 22:02:34] [EMAIL PROTECTED]
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.
[2005-06-27 21:16:37] jsheets at idahoimageworks dot com
Description:
Starting with PHP 5.1 beta #2 PHP dies with a
PHP Configuration:
'./configure' '--with-apxs2=/usr/local/apache2/bin/apxs'
'--with-pgsql=/usr/local/pgsql''--enable-ftp' '--with-zlib-dir=/usr'
'--with-config-file-path=/usr/local/apache2/conf'
'--with-jpeg-dir=/usr/local'
PHP Versions: 5.1 BETA #2 and PHP 5.1 latest CVS
Reproduce code:
---
/**
* Returns the part of the filename before the .
* @param string $file
* @return string
*/
function GetBaseName($file)
{
if (empty($file)) {
return false;
}
// simplified, $file replaced with file.txt
return array_shift(explode('.', 'file.txt')));
}
Expected result:
The expected result is that PHP returns the portion of the filename
before the .,
#33495 [Bgs-Opn]: Fatal error: Only variables can be passed by reference with array_shift
ID: 33495 User updated by: jsheets at idahoimageworks dot com Reported By: jsheets at idahoimageworks dot com -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: FreeBSD PHP Version: 5CVS-2005-06-27 (dev) New Comment: Opened again Previous Comments: [2005-07-18 20:58:25] jsheets at idahoimageworks dot com 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. [2005-07-18 20:54:27] [EMAIL PROTECTED] 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. [2005-07-18 20:44:58] jsheets at idahoimageworks dot com 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. [2005-06-28 09:10:37] [EMAIL PROTECTED] 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? [2005-06-28 01:40:37] jsheets at idahoimageworks dot com 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
#33495 [Bgs-Opn]: Fatal error: Only variables can be passed by reference with array_shift
ID: 33495
User updated by: jsheets at idahoimageworks dot com
Reported By: jsheets at idahoimageworks dot com
-Status: Bogus
+Status: Open
Bug Type: Scripting Engine problem
Operating System: FreeBSD
PHP Version: 5CVS-2005-06-27 (dev)
New Comment:
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.
Previous Comments:
[2005-06-27 22:02:34] [EMAIL PROTECTED]
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.
[2005-06-27 21:16:37] jsheets at idahoimageworks dot com
Description:
Starting with PHP 5.1 beta #2 PHP dies with a
PHP Configuration:
'./configure' '--with-apxs2=/usr/local/apache2/bin/apxs'
'--with-pgsql=/usr/local/pgsql''--enable-ftp' '--with-zlib-dir=/usr'
'--with-config-file-path=/usr/local/apache2/conf'
'--with-jpeg-dir=/usr/local'
PHP Versions: 5.1 BETA #2 and PHP 5.1 latest CVS
Reproduce code:
---
/**
* Returns the part of the filename before the .
* @param string $file
* @return string
*/
function GetBaseName($file)
{
if (empty($file)) {
return false;
}
// simplified, $file replaced with file.txt
return array_shift(explode('.', 'file.txt')));
}
Expected result:
The expected result is that PHP returns the portion of the filename
before the .,
Actual result:
--
Results in Fatal error: Only variables can be passed by reference
Error seems to have been introduced between beta 5.1 beta #1 and #2, it
works in PHP 4 as well as PHP 5.0.x and PHP 5.1 beta #1
--
Edit this bug report at http://bugs.php.net/?id=33495edit=1
