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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
