-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/29/2009 11:55 AM, Daniel Stenberg wrote:
> 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.
>
OK, I gave it some thought and I'm still not sure I understand -- if we
returned a single external structure, that would be easy, but since we
return an array, I'm afraid that would lead to ugliness in API.
Let's say we have a struct ares_private:
struct ares_private {
int magic;
void *data;
}
then, if the parsing function allocs struct ares_private *prv, you need
to offsetof starting at *address of data*, right?
prv == ((char *) &(prv->data) - offsetof(struct ares_private, data));
So, the parsing functions would need to return the address of data to
the user in order for the user to pass it back to the free function..and
now the user must deal with dereferencing, etc...this seems ugly to me..
So, what about a slight change in the external structures:
struct ares_srv_reply {
<data>
struct ares_srv-reply *next;
}
and have the private structure defined along the lines:
struct ares_private {
int magic;
union {
struct ares_srv_reply srv;
struct ares_txt_reply txt;
} data;
};
Sorry for such a long braindump on a ML, I'd just like to make sure
we're on the same page and avoid coding something that would be thown
away anyway :-)
Jakub
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkrrBEMACgkQHsardTLnvCWoXACbBT6yKbI0vCtWGqQN3cU2+w5G
nJcAoIm3mJNghOz43vDEwoeXIGSFuaS2
=Nc43
-----END PGP SIGNATURE-----
Received on 2009-10-30