Re: [PHP4BETA] Problem with refcounts and destructors (#2206)

Well, my API patches weren't 100% thorough; The way the various MySQL functions are written (which is more or less the way the rest of the functions in PHP are written) caused this symptom. I updated Zend accordingly, but in time, it's possible to optimize and improve the various functions that accept resource handles. Basically, in PHP 4.0, you shouldn't use convert_to_long() on the supplied resource ids, but instead, check whether the type of the resource id is IS_RESOURCE, and return an error if it's not. Zeev At 14:47 01/09/99 , Thies C. Arntzen wrote:

hi, i've reproduced this one (please apply attached patch to mysql.c to see the problem). script: <? $conn=mysql_connect("127.0.0.1"); for ($inx = 0; $inx < 10; $inx++) {

    $r = mysql_db_query("test", "select * from phptest");
    $array = mysql_fetch_array($r);
    mysql_free_result($r);

} echo "-----------------------end--------------\n";flush(); ?> this script does *NOT* (sorry for the emphasis) free the mysql-results while the script is running. ./php ./mysql.php3 new_result 0x081529e8 new_result 0x08153098 new_result 0x08153668 new_result 0x08153778 new_result 0x081538a8 new_result 0x081539b8 new_result 0x08153ac8 new_result 0x08153bd8 new_result 0x08153ce8 new_result 0x08153df8 Content-Type: text/html -----------------------end-------------- _free_mysql_result 0x081529e8 _free_mysql_result 0x08153098 _free_mysql_result 0x08153668 _free_mysql_result 0x08153778 _free_mysql_result 0x081538a8 _free_mysql_result 0x081539b8 _free_mysql_result 0x08153ac8 _free_mysql_result 0x08153bd8 _free_mysql_result 0x08153ce8 _free_mysql_result 0x08153df8 changing line 6 of the script to:

        $array = mysql_fetch_array(&$r);
                               ^ that's the trick

will get you: ./php ./mysql.php3 new_result 0x081529e8 _free_mysql_result 0x081529e8 new_result 0x08153050 _free_mysql_result 0x08153050 new_result 0x08153050 _free_mysql_result 0x08153050 new_result 0x08153050 _free_mysql_result 0x08153050 new_result 0x08153050 _free_mysql_result 0x08153050 new_result 0x08153050 _free_mysql_result 0x08153050 new_result 0x08153050 _free_mysql_result 0x08153050 new_result 0x08153050 _free_mysql_result 0x08153050 new_result 0x08153050 _free_mysql_result 0x08153050 new_result 0x08153050 _free_mysql_result 0x08153050 Content-Type: text/html -----------------------end-------------- but you need to call mysql_free_result: for ($inx = 0; $inx < 10; $inx++) {

    $r = mysql_db_query("test", "select * from phptest");
    $array = mysql_fetch_array(&$r);

// mysql_free_result($r); } gets you: new_result 0x08153098 new_result 0x08153668 new_result 0x08153778 new_result 0x081538a8 new_result 0x081539b8 new_result 0x08153ac8 new_result 0x08153bd8 new_result 0x08153ce8 new_result 0x08153df8 Content-Type: text/html -----------------------end-------------- _free_mysql_result 0x081529e8 _free_mysql_result 0x08153098 _free_mysql_result 0x08153668 _free_mysql_result 0x08153778 _free_mysql_result 0x081538a8 _free_mysql_result 0x081539b8 _free_mysql_result 0x08153ac8 _free_mysql_result 0x08153bd8 _free_mysql_result 0x08153ce8 _free_mysql_result 0x08153df8 which means that passing resource-id around ($r in this case) will cause problems. tc

Thies C. Arntzen                 "One Big-Mac, Small Fries and a Coke!"
Digital Collections             Phone +49 40 235350 Fax +49 40 23535180
Hammerbrookstr. 93                              20097 Hamburg / Germany

-- PHP 4 BetaFrom ???@??? Wed Sep 01 18:02:57 1999 Return-Path: <php4beta-return-3959-zeev-php4beta=zend.com@lists.php.net> Delivered-To: bourbon-zeev@bourbon.netvision.net.il Received: (qmail 2348 invoked by alias); 1 Sep 1999 13:05:23 -0000 Delivered-To: alias-zend-zeev-php4beta@zend.com Received: (qmail 2341 invoked from network); 1 Sep 1999 13:05:21 -0000 Received: from unknown (HELO php.net) (208.247.106.167) by bourbon.netvision.net.il with SMTP; 1 Sep 1999 13:05:21 -0000 Received: (qmail 5096 invoked by uid 510); 1 Sep 1999 12:05:51 -0000 Mailing-List: contact php4beta-help@lists.php.net; run by ezmlm Precedence: bulk Delivered-To: mailing list php4beta@lists.php.net Received: (qmail 5091 invoked from network); 1 Sep 1999 12:05:47 -0000 From: "Samuel Liddicott" <sam@campbellsci.co.uk> To: "Joey" <joey@samaritan.com>, "Sander Pilon" <sander@3dnews.net> Cc: "Scott Stevenson" <scott@maxify.com>, <php4beta@lists.php.net> Date: Wed, 1 Sep 1999 13:06:54 +0100 Message-ID: <NCBBLKJCFJLAJEDAIKEIOEHDFEAA.sam@campbellsci.co.uk> MIME-Version: 1.0 Content-Type: text/plain;

        charset="iso-8859-1"

Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <Pine.GSO.4.10.9909010519410.24773-100000@samaritan.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: [PHP4BETA] A quick clarification question about PHP4... X-UIDL: 01adb658f6bbe30d2f0ab56f9bdb5b6c -----Original Message----- From: Joey [mailto:joey@samaritan.com] Sent: Wednesday, September 01, 1999 12:25 PM To: Sander Pilon Cc: Samuel Liddicott; Scott Stevenson; php4beta@lists.php.net Subject: RE: [PHP4BETA] A quick clarification question about PHP4... I must admit, the "isset()" changes you are experiencing are (most likely) related more to the FIX of unset()...That is the documentation I was talking a/b. http://www.zend.com/downloads.php "A true unset() implementation. A variable or element that is unset(), is now sent to oblivion in its entirely, no trace remains from it." Are you having OTHER changes in isset()? I haven't seen any. Basically, you have most likely been programming around a semi-broken part of PHP3, and now it's time to clean all of that up... Ughh. How grim. Sure unnset can destroy the object referenced in the static variable, but to destroy the static-ness of the variable. How un-C/C++/whatever like!! This is very unnatural, I (in my ignorance) insist that php3 had it right, and that php3 behaves how I would naturally expect. It is a shock to see it behave this way in php4. I expect unset in a static variable to leave it unassigned now, and the next time the function is called. Its a bad feature to be able to temporarily turn a static variable into a temporary variable, and NOT BE ABLE to clear the contents without doing this! Howabout this, then, for a userland unset: function my_unset(&$x) { # any non-existant variable will do... $x=$unset; } This CAN safely be used on static variables. But can someone answer, whatever Zeev may have intended for php3 and however much the new behaviour may make his source code more poetic; who expects "un-staticize" to be a side effect of "un-set"? And seriously, when would any decent programmer actually WANT this behaviour? Is there really anybody who is actually now going to use unset() on static variables? And do we really expect people NOT to ask how they can persistantly un-set a static variable? Because surely this is the most common requirement. Also, is it deliberate that unset on a pass-by-reference argument ($&) unsets the local reference and not the contents of the passed variable? Is this part of the same thing? Sam -- PHP 4 Beta

-- Zeev Suraski <zeev@zend.com> http://www.zend.com/ For a PGP public key, finger bourbon@netvision.net.il