cvs: php-src /ext/mcve mcve.c

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; } /* }}} */