> 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
> g
> Im pretty sure you still need to 'efree' what you 'emalloc'. Every time
> I forgot to 'efree' something, I would get a bunch of error messages
> about memory leaks. The errors were nice and verbose, tho... as long as
> I was running the debug version of the dlls.
Which is what I would have ass
Im pretty sure you still need to 'efree' what you 'emalloc'. Every time
I forgot to 'efree' something, I would get a bunch of error messages
about memory leaks. The errors were nice and verbose, tho... as long as
I was running the debug version of the dlls.
So either the documentation is wro
> 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_para
Ok, according to my OReilly "Programming PHP" book by Rasmus Lerdorf,
the emalloc and efree functions work exactly the same as malloc and
free. It says:
-
if you emalloc() something and forget to efree() it, PHP prints a leak
warning like this if you are running in debug mode (enabled by
