5 ms·

So does Go, so a net.IP could be [16]byte or [4]byte, but I'm sure you can see the obvious problems that might occur there (with having two separate IP types).

So does Go, so a net.IP could be [16]byte or [4]byte, but I'm sure you can see the obvious problems that might occur there (with having two separate IP types). Most UUID libraries I've seen and written use [16]byte as the concrete UUID type.

dbaupp 10y ago
I don't see the obvious problem (fwiw, I really dislike such rhetorical devices): presumably net.IP could a struct that contains a [16]byte and an isV4 flag.
- int_19h 10y ago
  I think the point was that when it's a mere alias, you can end up passing an array of the right size and type that is not an IP address.
- barsonme 10y ago
  The problem is [16]byte would always be wasting 12 bytes for IPv4 addresses if you only used one type for both. So, two types must be made which requires extra code and doesn't allow for == comparison which is what OP (GP? whomever...) was complaining about not being able to do since net.IP is []byte. Sorry for the rhetorical device.
  - ben0x539 10y ago
    Isn't the indirection overhead of a []byte more expensive than a spare 12 inline bytes?
    - dbaupp 10y ago
      Yes, and a []byte is even going to have at least as much inline overhead: it stores 24 bytes (length, capacity, pointer), and of course plus the 4 bytes of actual data. Even on a 32-bit platform, the []byte inline storage is 12 bytes.
LeonidBugaev 10y ago
If you are using default library IPv4 addresses stores as [16]byte: https://golang.org/src/net/ip.go https://golang.org/src/net/ip.go
- daenney 10y ago
  I don't think that's what the Godoc says. The IP type is defined as []byte type IP []byte That is not the same as [16]byte. // Note that in this documentation, referring to an // IP address as an IPv4 address or an IPv6 address // is a semantic property of the address, not just the // length of the byte slice: a 16-byte slice can still // be an IPv4 address. What I believe that comment is saying is that something that is [16]byte can still be an IPv4 address, but that doesn't mean that all IPv4 addresses are stored as [16]byte. At least that would be my interpretation based on the comment above it: // An IP is a single IP address, a slice of bytes. // Functions in this package accept either 4-byte (IPv4) // or 16-byte (IPv6) slices as input.

dbaupp 10y ago

I don't see the obvious problem (fwiw, I really dislike such rhetorical devices): presumably net.IP could a struct that contains a [16]byte and an isV4 flag.

int_19h 10y ago
I think the point was that when it's a mere alias, you can end up passing an array of the right size and type that is not an IP address.
barsonme 10y ago
The problem is [16]byte would always be wasting 12 bytes for IPv4 addresses if you only used one type for both. So, two types must be made which requires extra code and doesn't allow for == comparison which is what OP (GP? whomever...) was complaining about not being able to do since net.IP is []byte. Sorry for the rhetorical device.
- ben0x539 10y ago
  Isn't the indirection overhead of a []byte more expensive than a spare 12 inline bytes?
  - dbaupp 10y ago
    Yes, and a []byte is even going to have at least as much inline overhead: it stores 24 bytes (length, capacity, pointer), and of course plus the 4 bytes of actual data. Even on a 32-bit platform, the []byte inline storage is 12 bytes.

LeonidBugaev 10y ago

If you are using default library IPv4 addresses stores as [16]byte: https://golang.org/src/net/ip.go https://golang.org/src/net/ip.go

daenney 10y ago
I don't think that's what the Godoc says. The IP type is defined as []byte type IP []byte That is not the same as [16]byte. // Note that in this documentation, referring to an // IP address as an IPv4 address or an IPv6 address // is a semantic property of the address, not just the // length of the byte slice: a 16-byte slice can still // be an IPv4 address. What I believe that comment is saying is that something that is [16]byte can still be an IPv4 address, but that doesn't mean that all IPv4 addresses are stored as [16]byte. At least that would be my interpretation based on the comment above it: // An IP is a single IP address, a slice of bytes. // Functions in this package accept either 4-byte (IPv4) // or 16-byte (IPv6) slices as input.