Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:18794 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 69199 invoked by uid 1010); 12 Sep 2005 07:57:33 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 69184 invoked from network); 12 Sep 2005 07:57:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Sep 2005 07:57:33 -0000 X-Host-Fingerprint: 204.11.219.139 lerdorf.com Linux 2.4/2.6 Received: from ([204.11.219.139:37957] helo=colo.lerdorf.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id F9/05-27924-CE435234 for ; Mon, 12 Sep 2005 03:57:32 -0400 Received: from [203.118.59.239] ([203.118.59.239]) (authenticated bits=0) by colo.lerdorf.com (8.13.4/8.13.4/Debian-4) with ESMTP id j8C7vOAR029045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Sep 2005 00:57:28 -0700 Message-ID: <432534E4.9020602@lerdorf.com> Date: Mon, 12 Sep 2005 15:57:24 +0800 User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: internals X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: ref fix revisited From: rasmus@lerdorf.com (Rasmus Lerdorf) Guys, could we take a look at making the ref to temp var fix a bit narrower? Currently we try to catch it at call-time. This means that something like: current(explode(' ','a b')) as per bug #34468 doesn't work. Now, I think there is a secondary bug here. I see no reason for current() to take a by-ref, so this particular one could be easily fixed. But there are many other cases where a function legitimately takes a by-ref and doesn't necessarily write to it or the write is a secondary action not required for the code to work. Could we not catch this on the write instead of on the call? The memory problem happens on the write. Or perhaps better, an E_NOTICE or E_STRICT on the call and an E_FATAL on the write. The current E_FATAL on the call seems out of whack. Gallery, for example, broke in a rather subtle way in their gallery_remote2.php script which meant the various client-side tools like iphototogallery and others got a cryptic "no album at URL" error message. I had to break out ethereal to track it down to a couple of functions where read-only function args were marked as by-ref. So they didn't actually have a memory corruption problem yet the E_FATAL killed them. 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. -Rasmus