3 ms·
Storing ipv4 addresses as 32bit numbers is common so I can certainly see a use for that.
by anshorei 6y ago
Storing ipv4 addresses as 32bit numbers is common so I can certainly see a use for that.
- chrisshroba 6y agoI'm not sure why you were downvoted. If this is true, it seems like it would save developers a conversion step when making a request.
- pierrebai 6y agoI would guess because the point of the number parsing is to end-up producing that final 32-bits value. If you already have the 32-bits value, there is no point in parsing it, so there is no point in supporting it in the address text parser. Like the article mention, supporting obscure features just makes it more likely that they can be exploited for nefarious purposes. It's not worth saving typing 4-5 characters from times to times. Before reading the article, I would have assumed for example that 127.1 would be 127.1.0.0, not 127.0.0.1.
- jolmg 6y ago> If you already have the 32-bits value, there is no point in parsing it, so there is no point in supporting it in the address text parser. There is a point when the only interface to that program is via text. You still have to convert the 32-bit value to text, but there's a difference between that and converting it to IPv4's dot notation. The former is simpler. > It's not worth saving typing 4-5 characters from times to times. I don't think the main users of the feature are people manually typing those addresses. > Before reading the article, I would have assumed for example that 127.1 would be 127.1.0.0, not 127.0.0.1. But then it wouldn't be a valid IP.
- deleted 6y ago[deleted]
- LambdaComplex 6y ago> > Before reading the article, I would have assumed for example that 127.1 would be 127.1.0.0, not 127.0.0.1. > But then it wouldn't be a valid IP. 127.1.0.0 is a perfectly valid IP address. The loopback range is a /8.
- jolmg 6y agoYou're right. I got confused a bit.