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]=-