Hacker News Reader

Comment by anshorei | Hacker News Reader

Storing ipv4 addresses as 32bit numbers is common so I can certainly see a use for that.

I'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.

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.

> 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.

> > 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.

You're right. I got confused a bit.

Reply on news.ycombinator.com