[EMAIL PROTECTED] writes:
> looking at 1.8, i noticed that host handling needs a total
> re-engineering.
I don't believe this. But I could be missing something.
> we should be carrying around sockaddrs (not in_addr)
> for IPv4/v6 support
The struct address_list was designed so that it doesn't specifically
depend on what it carries within. The CVS version already uses a
`ipv4_address_t' type rather than `unsigned char[4]':
struct address_list {
int count; /* number of adrresses */
ipv4_address *addresses; /* pointer to the string of addresses */
int faulty; /* number of addresses known not to
work. */
int refcount; /* so we know whether to free it or
not. */
};
So all we need to add for IPv6 is a tag specifying whether the
addresses contained are IPv4 or IPv6. The struct could then look like
this:
typedef unsigned char ipv4_address[4];
typedef ... whatever ... ipv6_address;
enum address_list_type { ADDRESSES_IPV4, ADDRESSES_IPV6 };
struct address_list {
enum address_list_type type;
int count; /* number of adrresses */
/* pointer to the string of addresses */
union {
ipv4_address *ipv4;
ipv6_address *ipv6
} addresses;
int faulty; /* number of addresses known not to
work. */
int refcount; /* so we know whether to free it or
not. */
};
Now the implementation functions will use addresses.ipv4 or
addresses.ipv6 depending on the type of the address_list.
A new function `address_list_type' can trivially return al->type and
thus notify the caller whether it's dealing with IPv4 or IPv6
addresses. Functions like "copy_one" will of course copy the correct
amount of data depending on al->type.
