Eliminate "family" field in tor_addr_t
The tor_addr_t structure has a "family" member that stores AF_INET, AF_INET6, or AF_UNSPEC. So in theory we'd need only 3 bits for it... but in practice, it bumps up the size of the structure by 4-8 bytes, because of alignment issues.
This excess space matters, because we allocate a whole lot of tor_addr_ts. For example, we allocate one for every exit policy entry.
We can save space here by using the "v4-mapped address" trick of RFC4291, and using ::ffff:1.2.3.4 as the representation of 1.2.3.4. For AF_UNSPEC, we can just choose a sentinel value.
Activity
changed milestone to %Tor: 0.3.4.x-final
See branch "short_address_rep" in my public repository for an implementation of this.
One thing to consider carefully here is that parsing what looks like an IPv6 address can create a value that gets construed as an IPv4 address or for AF_UNSPEC. (No valid IPv6 address will be taken for an one of those, but hostile input can happen.) We must look at all our code that parses potential IPv6 addresses carefully, to make sure that nothing will break because of this.
Trac:
Status: new to needs_review00:19 < wanoskarnet> re branch "short_address_rep": any explicitly non inited tor_addr_t structs will have AF_INET6 family, that hides exist family related bugs.The all-zero IPv6 address is used as
in6addr_anyby the IPv6 code, so if we use that as a special ‘uninitialized’ value oftor_addr_t, we'll have to do some careful fiddling to be able to specifyin6addr_anyin certain inputs and pass it to networking functions.-
00:19 < wanoskarnet> re branch "short_address_rep": any explicitly non inited tor_addr_t structs will have AF_INET6 family, that hides exist family related bugs.
I think the answer to that one is going to have to be: always use tor_addr_make_unspec, not memset(0), to initialize tor_addr_t fields.
Special-casing the address [::] seems like a bad move to me.
-
FWIW, I'm currently scared of this one, since if we forget tor_addr_make_unspec even one time, we wind up with 0.0.0.0 instead. It might make more sense instead to look for places where we allocate far too many tor_addr_t and we would benefit from saving the 4-8 bytes lost to the family field on each.
Alternatively, we could try to find some tricky way to make sure, mechanically, that every tor_addr_t got initialized. But I don't know a good solution on that one.
Trac:
Milestone: Tor: 0.2.4.x-final to Tor: unspecified moved to tpo/core/tor#4676 (closed)
