Re: [PATCH] ares_parse_txt_reply

On Thu, 29 Oct 2009, Jakub Hrozek wrote:

>> 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.
>
> Well, from the point of view of the API user something along the lines of
> ares_free() sure sounds good.
>
> How did you envision the implementation? Because some parsing functions use
> standard structures (hostent), in order to expand the returned data you
> either wrap the standard structures in ares specific ones that would carry
> the hint or return the hint as another parameter..both ways would change the
> API..

Right, those that return a "standard struct" we can't do much about. I really
don't think we should add new APIs that return such structs but we can leave
the exsisting as they are to not stir anything up.

For the ones that return an ares struct, we can either select to show the
magic to the user or hide it from the users by doing it:

  struct ares_hidden {
    int magic;
    struct ares_external {
      int public;
    }
  }

  The ares_free() function would then use 'offsetof()' to figure out the
  start address of the 'ares_hidden' struct, check what type that is embedded
  and then call the appropriate internal free function.

  And when we return a pointer to this struct over the API, we just return a
  pointer to the external part.

  Or we let the magic get seen by the user :

   struct ares_external {
     int hidden; /* c-ares internal variable, don't touch! */
     int public;
   }

  I think I prefer the first approach. Mostly because the second approach makes
the magic visible in the public struct and then we need to document it and so
on and it makes it less nice.

-- 
  / daniel.haxx.se