On Oct 28, 2003, at 4:02 PM, Biot Olivier wrote:
I'm not sure, but there still exists a possibility to leak memory or
to dump
core when freeing memory we *think* is allocated, unless we are 100%
certain
that all pointer values in the fvalue structure are always initialized
to
NULL (something available via fvalue_new but I'm not certain that we
always
call fvalue_new...),
I did not find any code path that did not use "fvalue_new()".
and that in all other cases the value may be freed
safely (and in fact must be if we don't want to leak memory).
The only types with allocated memory are FT_BYTES, the various string
types and FT_PROTOCOL.
I have checked in a change to make all methods that set the values for
those types free any previously-allocated value, if necessary (the
free-the-value routine for the type is called).
Both paths can be walked anyway, and I'd be glad to provide a patch
based on
the preference of the majority. But I'm just afraid that assuming that
a
NULL fvalue pointer means the same as "the value has never been
initialized"
may break something at unexpected parts in the code. Although it's
worth
giving it a try :)
Yes, it's worth giving it a try, which is why I did that.
I checked in the aforementioned change, as well as a change that adds
"proto_item_append_string()", which is based on
"proto_tree_append_string()", but
1) just uses "fvalue_set()";
2) has no "tree" or "hfindex" arguments, as they're unnecessary - the
"proto_item" argument is sufficient;
3) returns no value.