Re: [PATCH hail] lib/hstor.c: avoid an unconditional leak in append_qparam

Jim Meyering <[email protected]> Mon, 27 Sep 2010 19:05:47 +0200
Newsgroups org.kernel.vger.hail-devel
Message-ID <[email protected]>
Pete Zaitcev wrote:
> On Mon, 27 Sep 2010 10:53:06 +0200
> Jim Meyering <[email protected]> wrote:
>
>> -	stmp = huri_field_escape(strdup(val), QUERY_ESCAPE_MASK);
>> +	v = strdup(val);
>> +	stmp = huri_field_escape(v, QUERY_ESCAPE_MASK);
>>  	str = g_string_append(str, stmp);
>>  	free(stmp);
>> +	free(v);
>
> I think you may be fooled by the ridiculous calling convention
> of huri_field_escape(). It takes a pointer to heap, then either
> returns its argument, or reallocates it, frees the argument, and
> returns the reallocated area. It frees with g_free, so it assumes
> its equivalence with free(), haha.
>
> The end result, it either returns what strdup returned of frees it.
> Therefore if you free what strudup returned, you double-free it.

Oh!  You're right.
I missed the "g_free (signed_str);"
at the end of huri_field_escape.
Sorry about that.

> I honestly think this madness must stop and huri_field_escape
> must allocate a new buffer every time. Then we would not need
> the strdup there at all. It only exists to satisfy the requirement
> to pass a pointer to heap in case val is a const or whatnot.

Making a function like huri_field_escape free
a buffer allocated by the caller does seem to violate
something fundamental.