Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:2903 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 94695 invoked from network); 27 Jun 2003 18:30:30 -0000 Received: from unknown (HELO herald.cc.purdue.edu) (128.210.11.29) by pb1.pair.com with SMTP; 27 Jun 2003 18:30:30 -0000 Received: from localhost (wm-cpu5.itcs.purdue.edu [128.210.11.237]) by herald.cc.purdue.edu (8.12.9/8.12.9/herald) with ESMTP id h5RIUTkW001716 for ; Fri, 27 Jun 2003 13:30:29 -0500 (EST) Received: from 204.180.78.219 ([204.180.78.219]) by webmail.purdue.edu (IMP) with HTTP for ; Fri, 27 Jun 2003 13:18:32 -0500 Message-ID: <1056737912.3efc8a7881a32@webmail.purdue.edu> Date: Fri, 27 Jun 2003 13:18:32 -0500 To: internals@lists.php.net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2-cvs Subject: [PATCH] extend zend_parse_parameters() functionality (2nd attempt) From: fuhs@purdue.edu Hello, I propose that a new type, 'Z', be added in order to allow the extension coders access to the zval** which was available with the now deprecated zend_get_parameters(). I came to this conclusion after tracing some segfaults to a section of code similar to this: zval *zend_value; if(zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z", &zend_value) == FAILURE) return; convert_to_array_ex(&zend_value); I realized after sifting through the Zend code that the proper handling of zval* types is just as important as that of the zval's. This modification will give extension programmers access to legitimate zval*'s and their corresponding zval. Zend/zend_API.c RELEASE ver 4.3.1 425c425,434 < --- > case 'Z': > { > zval ***p=va_arg(*va, zval ***); > if(Z_TYPE_PP(arg) == IS_NULL && return_null){ > *p = NULL; > } else { > *p = arg; > } > } > break; 474c483 < case 'z': --- > case 'z': case 'Z': Josh