Re: [PATCH] ares_parse_txt_reply

On Wed, 28 Oct 2009, Jakub Hrozek wrote:

> Yes, that is a bug. I think the best solution might be to provide a free
> function and use it both internally in cases like this and provide it
> externally.

Right, we have that problem with these functions allocating memory that is
returned so we need to provide a function that can free that memory (we cannot
assume the app can use free() to free memory returned by our lib).

I remember we got a ares_free_txt_reply() function before (that isn't in CVS
and that isn't properly referenced to from the ares_parse_txt_reply man page
etc). Do you think it would make sense that we perhaps instead try to unify
how we deal with allocated memory handed out in the API so that we can have a
single function that can do the free? I really don't like that we're
progressing towards adding a new free function for every new parse function.

All it would take is that we make sure we include a hint in the returned data
about what struct it is so that we can detect that in the free function and
then do the correct cleanup.

Thoughts?

-- 
  / daniel.haxx.se