On Wed, 2008-11-26 at 22:45 +0100, Daniel Stenberg wrote:
> On Wed, 26 Nov 2008, Phil Blundell wrote:
>
> > 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.
>
> Thinking even further, we could probably even rename the old ARES_OPT_SERVERS
> to ARES_OPT_SERVERS_OLD and introduce the new ARES_OPT_SERVERS with a new bit
> (and do similar with the 'servers' and 'nservers' firleds) and then not break
> ABI (as existing apps will continue to run), but recompiles will automatically
> use the new way...
>
> Or am I wrong?
The old "servers" member of struct ares_options is just a struct
in_addr*, which isn't forwards compatible with IPv6 since this struct is
only 32 bits long. In order to make an option which works with both,
you'd need to change this to be struct ares_addr* or some other thing
which includes an address family member. Since this new structure needs
to be filled in differently, it isn't API compatible, so a simple
recompile won't work: the calling application needs to know how to
populate it with the right bits.
p.
Received on 2008-11-26