Hi Gün,
2009/10/11, Guenter wrote:
> isnt the change
> http://article.gmane.org/gmane.comp.web.curl.cvs/12383
> now obsolete after you changed the type of addrlen with
> http://article.gmane.org/gmane.comp.web.curl.cvs/12384
> ??
Nah! It is still required to silence an HP-UX bogus compiler warning
related with an out-of-bounds memory overwrite.
> BTW I just saw that ares__get_hostent.c still uses:
> struct in_addr addr;
> struct in6_addr addr6;
> although in ares.h you can read at line 299ff:
> /*
> * NOTE: before c-ares 1.6.1 we would most often use the system in6_addr
> * struct below when ares itself was built, but many apps would use this
> * private version since the header checked a HAVE_* define for it. Starting
> * with 1.6.1 we always declare and use our own to stop relying on the
> * system's one.
> */
> struct ares_in6_addr {
> union {
> unsigned char _S6_u8[16];
> } _S6_un;
> };
Hmm. That comment in ares.h might be a bit misleading 'ares_in6_addr'
is actually only used in ares.h to provide the in6_addr definition for
the addr6ttl struct. Using ares_in6_addr' avoids the need to include
additional system headers in ares.h on systems that do have in6_addr.
Internally c-ares doesn't use 'ares_in6_addr' it uses 'in6_addr' all
over the place, not only in ares__get_hostent.c, actually using the
system provided 'in6_addr' definition except on those systems which
don't have it, using then the internal definition from ares_ipv6.h
> shouldnt we change ares__get_hostent.c to use this struct instead of
> in6_addr?
I don't think so. its easier to read 'in6_addr' than 'ares_in6_addr',
besides that internally we are using the system in6_addr definition
when available, and that if changed the change should be done in all
places not just in ares__get_hostent.c.
-- -=[Yang]=-Received on 2009-10-12