bradmssw Wed Aug 20 15:45:07 2003 EDT
Modified files:
/php-src/ext/mcve mcve.c
Log:
allow destructor to clean up connection data
Index: php-src/ext/mcve/mcve.c
diff -u php-src/ext/mcve/mcve.c:1.22 php-src/ext/mcve/mcve.c:1.23
--- php-src/ext/mcve/mcve.c:1.22 Sun Aug 3 13:44:36 2003
+++ php-src/ext/mcve/mcve.c Wed Aug 20 15:45:06 2003
@@ -17,7 +17,7 @@
+----------------------------------------------------------------------+
*/
-/* $Id: mcve.c,v 1.22 2003/08/03 17:44:36 zeev Exp $ */
+/* $Id: mcve.c,v 1.23 2003/08/20 19:45:06 bradmssw Exp $ */
/* standard php include(s) */
#include "php.h"
@@ -508,10 +508,17 @@
if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &arg) == FAILURE)
WRONG_PARAM_COUNT;
+/* If MCVE_DestroyConn() is called within a PHP script, the Resource handle is
+ never cleared, as there does not appear to be an UNREGISTER or DESTROY resource
+ call in the Zend API. What happens is this uninitialized memory location is
+ passed again to the MCVE_DestroyConn() function at script exit (cleanup), and
+ causes weird stuff. So we just go ahead and let the PHP garbage collector call
+ our _free_mcve_conn() we registered (le_conn) to clean up */
+#if 0
ZEND_FETCH_RESOURCE(conn, MCVE_CONN *, arg, -1, "mcve connection", le_conn);
MCVE_DestroyConn(conn);
-
+#endif
RETURN_TRUE;
}
/* }}} */
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
