[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Tor Ipv6-Patch
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