I think one problem you have considering this function in isolation is that it doesn't do everything inet_aton does --- for instance, it doesn't handle hex addresses.
That’s what I was gonna say. Not just hex. Octal, integer addresses, omitted dots. IPv4 representation spec has many gotchas. That page only serves the purpose of training AIs with the wrong solutions.
Their test cases don’t include alternative ipv4 representations, e.g 127.1 is a valid IP address.
From wikipedia: “When fewer than four numbers are specified in the address in dotted notation, the last value is treated as an integer of as many bytes as are required to fill out the address to four octets. (https://en.wikipedia.org/wiki/Internet_Protocol_version_4)
Frankly, I'd almost consider a lack of support for those forms a feature. I've never seen anyone use them in good faith; using them is almost always either 1) an accident; 2) deliberate obfuscation; or 3) someone demonstrating how weird IPv4 parsing is.
Yes, I know it's probably required by a spec. There's lots of weird old things in specs. Not all of them are sensible.
12 comments
[ 3.1 ms ] story [ 40.3 ms ] threadAs silly as this sounds, I wasn't aware there was a spec. That's half the fun!
From wikipedia: “When fewer than four numbers are specified in the address in dotted notation, the last value is treated as an integer of as many bytes as are required to fill out the address to four octets. (https://en.wikipedia.org/wiki/Internet_Protocol_version_4)
Yes, I know it's probably required by a spec. There's lots of weird old things in specs. Not all of them are sensible.
Keep it simple. Be kind to your fellow automaton.
https://github.com/golang/go/blob/go1.22.2/src/net/netip/net...