Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:2413
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <1055997182.3ef13cfeba6ea@webmail.purdue.edu>
Date: Wed, 18 Jun 2003 23:33:02 -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
From: fuhs@purdue.edu

Hello,

I'm new to the world of contributing code for open source projects. Please let
me know if I'm doing something incorrectly.

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':


On a side note, since zval*'s and zvals are both controlled resources, it would
be nice to see an API that completely handles their use.

For example:

    /* Zend already makes a distinction between
       variables and values. Hence the refcount. 
       This idea could be reflected in the API. */
    typedef zval** zvar;  /* Named 'zvar' for the sake of argument. */

    zvar zvar_new();

    void zvar_destroy();

    #define zvar_convert_to_*(ZVAR) convert_to_*_ex(ZVAR)

    #define ZVAR_STRING(ZVAR, STRING, DUP) do{ 
        SEPARATE_IF_NOT_REF(ZVAR); 
        ZVAL_STRING(*((zval**)ZVAR), STRING, DUP); 
       while(0)

    etc    

This would make extension creation much more friendly, and, as long as this API
is used, there should never be a worry that one is changing Zend internal data
in an inappropriate manner.

Josh