Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:18955 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 28974 invoked by uid 1010); 15 Sep 2005 11:03:52 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 28959 invoked from network); 15 Sep 2005 11:03:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Sep 2005 11:03:52 -0000 X-Host-Fingerprint: 204.11.219.139 lerdorf.com Linux 2.4/2.6 Received: from ([204.11.219.139:36225] helo=colo.lerdorf.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 18/6E-41173-81559234 for ; Thu, 15 Sep 2005 07:03:52 -0400 Received: from [192.168.2.104] (CPE00131063dcac-CM0011aec551ea.cpe.net.cable.rogers.com [65.49.170.67]) (authenticated bits=0) by colo.lerdorf.com (8.13.4/8.13.4/Debian-4) with ESMTP id j8FB3enx030023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Sep 2005 04:03:42 -0700 Message-ID: <4329550B.90303@lerdorf.com> Date: Thu, 15 Sep 2005 07:03:39 -0400 User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Leigh Makewell CC: internals@lists.php.net References: <43276022.6020702@encode.net.au> <7C.1C.41173.4D828234@pb1.pair.com> <63.BA.41173.BB6E8234@pb1.pair.com> <4328EFC1.3030500@lerdorf.com> <38.3D.41173.B58F8234@pb1.pair.com> <4328F9DC.40302@lerdorf.com> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Reference handling change and PHP 4.4.0 From: rasmus@lerdorf.com (Rasmus Lerdorf) Leigh Makewell wrote: > Rasmus Lerdorf wrote: > >> Well, that is the point, it didn't actually work. Code similar to this >> caused memory corruption. So while you may not have seen an instant >> crash, over time and in certain conditions you would get unexplained >> crashes. In order to fix this bug we needed to check for this sort of >> code and in doing so we were able to fix it and also enhance the warning >> levels to let people detect this sort of potentially bogus code. >> >> -Rasmus > > You don't seem to understand. I'll let you in on a secret. We don't care > about the php engine and how it works. What we care about is the PHP > code and whether that works. Like it or not you set a precedent. You > allowed us to write code that worked. Maybe it didn't work 100% and > occasionally caused a crash, but that doesn't change the fact it worked. > It must of worked otherwise people wouldn't of written it that way. That's fine, and you shouldn't care, I agree. I argued much the same point just yesterday in a chat with Ilia. You do however seem to be glossing over the fact that this new check can be very helpful. Take this case: sort(array(3,2,1)); Or any other example where the function in question has no other purpose than to modify its argument. When you pass in something to a function like this which has no permanent storage, chances are pretty high that this is a bug in the code and you probably want to know about that. So I really don't see this as such a black and white case. I am all for making this a non-fatal error in all cases to allow scripts to keep working, but I don't buy the argument that just because we didn't check for this before we are not allowed to check for it now when it can find valid bugs like this. -Rasmus