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.