On Mon, Nov 24, 2008 at 04:02:29PM +0100, Yang Tse wrote:
> > The reSIProcate developers substituted the in_addr field by an union
> > contruct to hold the in6_addr. As this would break API compatibility, I
> > have added a second nservers and servers field and suffixed it with a '6'.
>
> For c-ares, instead of having two lists of name servers, I think that
> keeping a single one and being able to differentiate between an Ipv6
> address name server and an Ipv4 one should keep things working more
> smoothly and aid in code maintainability.
I think because of ares_version.h the application developers could
easily support older and newer versions of c-ares with the help of some
preprocessor magic.
> This could be done building upon the following change:
>
> Index: ares/ares_private.h
> ===================================================================
> RCS file: /cvsroot/curl/curl/ares/ares_private.h,v
> retrieving revision 1.39
> diff -u -r1.39 ares_private.h
> --- ares/ares_private.h 20 Nov 2008 07:50:48 -0000 1.39
> +++ ares/ares_private.h 24 Nov 2008 14:35:16 -0000
> @@ -132,7 +132,9 @@
> };
>
> struct server_state {
> - struct in_addr addr;
> + int af; /* server address family */
> + union ares_addr; /* server address */
> +
> ares_socket_t udp_socket;
> ares_socket_t tcp_socket;
Thanks for your comments. The ares options server array is now of the
type:
struct ares_af_addr {
int af;
union ares_addr addr;
};
because I need to store the address family, too. Attached you find two
versions of the patch. One, the struct one, uses the new struct
ares_af_addr also in struct server_state, the union one uses an int and
the union directly.
I've replaced the memcpy in adig with a simple assignment (and also just
assign struct ares_af_addr in ares_init.c). Does this cause problems on
alignment sensitive platforms or is the compiler supposed to handle
this?
Thanks,
Gregor