5 ms·

The uintptr / SetFinalize trick to implement "weak" references is pretty cool, but I'd be curious to hear why type IP struct { hi, lo uint64

The uintptr / SetFinalize trick to implement "weak" references is pretty cool, but I'd be curious to hear why type IP struct { hi, lo uint64 z string } with sentinel strings like "\04" and "\0\06" for IPv4 and IPv6-no-zone was rejected. Sure, this 8 bytes larger for the implicit string length, but its still not terribly large, and the string comparisons in the normal IPv4 / IPv6 case are very cheap (just length and pointer equality checks). And it doesn't require opening the unsafe jar. Was the extra 8 bytes enough to disqualify it? Or are the authors worried about the fact that this may allocate on each parse of an IPv6-with-zone?

bradfitz 6y ago
Yeah, that would be the obvious representation if we were willing to go to 32 bytes. (on 64-bit) But paying 8x memory cost for IPv4 and 2x for IPv6 was a bit hard to swallow. Especially considering how rare IPv6+zones are. And we didn't want to have be worse in any regard compared to std's net.IP. If we went to 32 bytes then Go's net.IP would win if you parsed an IP and stored it multiple times. Because we'd be a 32 byte value type and Go would be a 24 byte value type containing a pointer to the shared-for-all-copies address bits. Sure, they'd all be aliasing the same memory (danger zone!) but in Go the culture is to behave and risk that. But staying at 24 bytes, we're never worse than net.IP and strictly better in all regards. (at least by the metrics we highlighted in the blog post... perhaps not by "don't play unsafe shenanigans with IPv6 zone interning")
- gilgad13 6y ago
  Fair enough. I agree 8x for IPv4 would be hard to swallow. In either case, having the interning wrapped up in a reusable library is great.
- ash 6y ago
  > Especially considering how rare IPv6+zones are. Who uses IPv6+zones and why? I'm confused what zones are about. They don't seem to be part of IPv6 packets. Where do they come from? Why does IP type have to deal with them?
  - ash 6y ago
    One answer to "who?" question: https://news.ycombinator.com/item?id=26419035 https://news.ycombinator.com/item?id=26419035 Still unclear why and where do zones come from.
  - ash 6y ago
    This was helpful: https://en.wikipedia.org/wiki/IPv6_address#Scoped_literal_IPv6_addresses_(with_zone_index) https://en.wikipedia.org/wiki/IPv6_address#Scoped_literal_IP... Apparently it's possible to embed interface name into an address: fe80::1ff:fe23:4567:890a%eth2 The article also points to an alternative solution - embed interface index into an address: fe80:3::1ff:fe23:4567:890a
  - fanf2 6y ago
    A scoped IPv6 address contains a network interface name, which is used to disambiguate which network a link-local address belongs to. It’s relatively common to encounter them in some network configurations where the routers use link-local addresses rather than global addresses in their RA packets. They are also used in SLAAC, because a device can configure a link-local address without knowing anything about its environment. [ I think in the past there might have been an idea to use them to disambiguate site-local IPv6 addresses, but network interfaces are not sufficient in that case, and site-local addresses were problematic in lots of other ways, so they have been dropped from the specifications. ]

bradfitz 6y ago

Yeah, that would be the obvious representation if we were willing to go to 32 bytes. (on 64-bit) But paying 8x memory cost for IPv4 and 2x for IPv6 was a bit hard to swallow. Especially considering how rare IPv6+zones are. And we didn't want to have be worse in any regard compared to std's net.IP. If we went to 32 bytes then Go's net.IP would win if you parsed an IP and stored it multiple times. Because we'd be a 32 byte value type and Go would be a 24 byte value type containing a pointer to the shared-for-all-copies address bits. Sure, they'd all be aliasing the same memory (danger zone!) but in Go the culture is to behave and risk that. But staying at 24 bytes, we're never worse than net.IP and strictly better in all regards. (at least by the metrics we highlighted in the blog post... perhaps not by "don't play unsafe shenanigans with IPv6 zone interning")

gilgad13 6y ago
Fair enough. I agree 8x for IPv4 would be hard to swallow. In either case, having the interning wrapped up in a reusable library is great.
ash 6y ago
> Especially considering how rare IPv6+zones are. Who uses IPv6+zones and why? I'm confused what zones are about. They don't seem to be part of IPv6 packets. Where do they come from? Why does IP type have to deal with them?
- ash 6y ago
  One answer to "who?" question: https://news.ycombinator.com/item?id=26419035 https://news.ycombinator.com/item?id=26419035 Still unclear why and where do zones come from.
- ash 6y ago
  This was helpful: https://en.wikipedia.org/wiki/IPv6_address#Scoped_literal_IPv6_addresses_(with_zone_index) https://en.wikipedia.org/wiki/IPv6_address#Scoped_literal_IP... Apparently it's possible to embed interface name into an address: fe80::1ff:fe23:4567:890a%eth2 The article also points to an alternative solution - embed interface index into an address: fe80:3::1ff:fe23:4567:890a
- fanf2 6y ago
  A scoped IPv6 address contains a network interface name, which is used to disambiguate which network a link-local address belongs to. It’s relatively common to encounter them in some network configurations where the routers use link-local addresses rather than global addresses in their RA packets. They are also used in SLAAC, because a device can configure a link-local address without knowing anything about its environment. [ I think in the past there might have been an idea to use them to disambiguate site-local IPv6 addresses, but network interfaces are not sufficient in that case, and site-local addresses were problematic in lots of other ways, so they have been dropped from the specifications. ]