3 ms·
I 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
by pierrebai 5y ago
I 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 5y 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 5y ago[deleted]
- LambdaComplex 5y 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 5y agoYou're right. I got confused a bit.