Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:18879
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <19.93.41173.99A18234@pb1.pair.com>
To: internals@lists.php.net
Date: Wed, 14 Sep 2005 14:41:52 +0200
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
References: <432534E4.9020602@lerdorf.com>
In-Reply-To: <432534E4.9020602@lerdorf.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: ref fix revisited
From: akorthaus@web.de (Andreas Korthaus)

Rasmus Lerdorf wrote:

> SquirrelMail has code like this all over the place:
> 
>    $value = strtolower(array_shift(split('/\w/',trim($value))));
> 
> Here array_shift() does of course change the arg, so that is a potential
> problem.  And yes, that's a dumb way to do this, but people write code
> like this.  In some of these array manipulation calls, which seems to
> account for a number of the BC problems we are having, we could check
> for a non-ref and behave slightly differently.  In the case of
> array_shift() we could return the first arg and throw a notice.  Same
> would go for reset(), end(), next(), prev() and probably a few others.

I noticed the same problem with array_pop(). I'm happy with the new 
fatal error for user-space functions. But nobody - at least non-devs - 
knows that functions like array_pop() may not be used the way you 
described here anymore. It's not documented somewhere and it's hard to 
understand why. Many PHP programmers put more than one function in a row 
(I know it's bad style), so there a lot of such code out there.

Would be great if that behaviour could be fixed.

What I don't understand - upgrading from 5.0.4 to 5.0.5 broke by far 
more applications on my servers, than upgrading from 4.x to 5.x! And 
there was no information in the News/ChangeLog.
For an admin it looked like a small, non-BC-braking security update 
which should be installed as soon as possible, without any risk to break 
scripts working with PHP 5.0.4.
And in 5.0.5 it's fatal error, not only notice.


best regards
Andreas