Some additional brainstormin on the generic ares free function...
Would it be ok that the purpose of a c-ares external API
ares_freedata() function is to allow the calling application to free
memory resources that have been internally allocated by some c-ares
function and for which a pointer has already been returned to the
calling application?
It could be made generic enough as to be able to handle c-ares
structs, arrays of c-ares structs, strings, linked lists or whatever
we want. It could even handle the same for structs which are defined
elsewhere. In order to not break ABI, the only 'requisite' would be to
perfectly define which c-ares functions returning pointers to memory
allocated by c-ares require calling this ares_freedata() function.
The private data structure could be something like:
struct ares_data {
ares_datatype type;
unsigned int mark;
void *data;
};
Where ares_datatype could initially be for example something like:
typedef enum {
ARES_DATATYPE_UNKNOWN = 1,
ARES_DATATYPE_ADDR6TTL_PTR,
ARES_DATATYPE_ADDRTTL_PTR,
ARES_DATATYPE_HOSTENT_PTR,
ARES_DATATYPE_OPTIONS_PTR,
ARES_DATATYPE_SRV_REPLY_PTR,
ARES_DATATYPE_TXT_REPLY_PTR,
ARES_DATATYPE_LAST
} ares_datatype;
The pointer that c-ares functions using this would return would be the
'data' pointer of the ares_data struct. Later on This would be the
pointer that the calling application should pass to ares_freedata() to
free all the resources that c-ares had previously allocated.
The 'mark' member of the ares_data struct, would be a fixed signature
mark intended for the purpose of validating if a received pointer is a
pointer of something that actually was allocated by c-ares using the
ares_data struct 'mechanism'.
Comments?
-- -=[Yang]=-Received on 2009-11-01