On Wed, Nov 26, 2008 at 11:48:49PM +0100, Gregor Jasny wrote: > On Wed, Nov 26, 2008 at 09:26:03PM +0000, Phil Blundell wrote: > > On Wed, 2008-11-26 at 20:29 +0100, Yang Tse wrote: > > > As you have already mentioned it breaks ABI compatibility due to the > > > change it introduces in one of the ares_options structure member. Yes > > > the affected member is the 'servers' member which changes its data > > > type. And the change is unavoidable if we want to support ipv6 > > > servers. > > > > It isn't completely unavoidable: one could create a new option, say > > ARES_OPT_IPV6_SERVERS, with a corresponding new member at the end of > > struct ares_options, to be used by new applications. (Obviously, > > despite the name, you could in fact pass both v4 and v6 servers through > > this interface.) Since the applications need to change anyway to pass > > in v6 servers, this doesn't seem like it would be much of a problem. > > Old sources and binaries would go on passing ARES_OPT_SERVERS and > > filling in the old "servers" member, which would continue to work just > > fine. > > Good point. I'll prepare a patch on top of Yangs.
I've just noticed, that extending the ares_options struct will definitely break ABI compatibility: The new ares_save_options would write behind the old allocated option space when saving the new option. So a major number bump seems unavoidable. And if a recompilation is necessary, I don't know if its worth the trouble of keeping two different lists in the options struct. Maybe you could add something like this into the release notes: #include <ares_version.h> ... #if ARES_VERSION > 0x010503 opt.servers = malloc (sizeof(struct ares_addr)); opt.servers[0].family = AF_INET; opt.servers[0].addr.addr4.s_addr = ntohl(INADDR_LOOPBACK); #else opt.servers = malloc (sizeof(struct in_addr)); opt.servers[0].s_addr = ntohl(INADDR_LOOPBACK); #endif ... In Debian the only two packages depending on c-ares don't use the ARES_OPT_SERVERS at all, so a simple recompile will be sufficient. Cheers, Gregor
