Tor Ipv6-Patch

[Michael G. Reed]

On Tue, 4 Dec 2007, Marcus Wolschon - Wolschon Softwaredesign wrote:
|> >  - You're right that the preferred way to store addresses that could be
|> >    either IPv4 or IPv6 is indeed with tor_addr_t.  (Thanks for the
|> >    reminder, BTW: I fixed tor_addr_t to be a tagged union of in_addr and
|> >    in6_addr, not of sockaddr_in and sockaddr_in6.)
|> 
|> do you want to do the refactoring to use tor_address_t or shall I?
|> So we need a pair of tor_address_t and int socket_family. Wouldn't it
|> be better to have the socket_family in a struct with the tor_address_t
|> - -union? That way it would probably be a drop-in -replacement for the
|> 32bit-addresses.

This is exactly why multi-protocol developers normally use
sockaddr_storage to define the space for an address they do not know
the type of in advance and then rely on the sa_family field to
differentiate.  sockaddr_storage is guaranteed to be large enough to
hold the largest supported address type in the system (not
efficient/desirable/usable for on-the-wire, but is best used in
application processing).

-Michael