RE: [PHP-WIN] Re: Question about emalloc
| From: | Rasmus Lerdorf | Date: | Thu, 17 Oct 2002 21:50:44 +0000 |
| Subject: | RE: [PHP-WIN] Re: Question about emalloc | ||
| References: | 1 | Groups: | php.windows |
| Request: | Send a blank email to php-windows+get-16433@lists.php.net to get a copy of this message | ||
> 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