> Well, I decided to see how the big boys dealt with strings, and had a root
> around ext/standard. The following function is from string.c:
>
> PHP_FUNCTION(bin2hex)
> {
> zval **data;
> char *result;
> size_t newlen;
>
> if (ZEND_NUM_ARGS() != 1 ||
> zend_get_parameters_ex(1, &data) == FAILURE) {
> WRONG_PARAM_COUNT;
> }
> convert_to_string_ex(data);
>
> result = php_bin2hex(Z_STRVAL_PP(data), Z_STRLEN_PP(data), &newlen);
>
> if (!result) {
> RETURN_FALSE;
> }
>
> RETURN_STRINGL(result, newlen, 0);
> }
>
> As you can see, result is emalloc()'d, but not efree()'d at the end - looks
> like the docs are right. I have since tried using this approach in a test
> function and do not get any errors when I compile - what do you use for your
> build?
The result is efreed in that case. RETURN_STRINGL is a macro that assigns
result to return_value and return_value is implicitly efreed by PHP.
That's the only reason you are not getting a warning in that case. For
other stuff that you emalloc but don't assign to return_value, you will
get a warning if you do not efree it.
-Rasmus
--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
