ID: 33495 Updated by: [EMAIL PROTECTED] Reported By: jsheets at idahoimageworks dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: FreeBSD PHP Version: 5CVS-2005-06-27 (dev) New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [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 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 ., 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=33495&edit=1
