Find a different ping or inet_aton implementation and it won't necessarily work.
At best, you seem to be picking nits. More likely though I think you just have a very surface level understanding of what is going on here.
The bottom line is that, as I said already, an IPv4 address is a 32 bit number. It's also true that various tools that communicate with IP addresses utilize different methods to arrive at the underlying 32 bit number. But it's not right to say that "this only applies to systems using ping from iptools and glibc" as the article you linked says. Many of these "tricks" worked in all manner of operating systems and applications. I was discussing many of them in IRC using Windows 3.1 and Trumpet Winsock before 1994.
Again, the bottom line is that an IPv4 IP address is a 32 bit number and there are dozens of ways that various applications allow you to arrive at that number. It's silly for an article or someone quoting it to attempt to say it only applies to one implementation.
I rather think they're talking about different things.
Rachel analyzed things from the bottom up, seeing the scope of how much worked from the implementation. But the flexibility of an implementation doesn't tell you much about the specification, as implementations are usually more lenient and broad than the specification.
300bps is talking about how in_addr is a 32-bit structure and indeed contains s_addr; IPv4 addresses are fundamentally 32-bit unsigned integers.
To actually shed some light on this one would need to look into the specified encoding of in_addr in URLs.
Although the URI syntax for IPv4address only allows the common
dotted-decimal form of IPv4 address literal, many implementations
that process URIs make use of platform-dependent system routines,
such as gethostbyname() and inet_aton(), to translate the string
literal to an actual IP address. Unfortunately, such system routines
often allow and process a much larger set of formats than those
described in Section 3.2.2.
For example, many implementations allow dotted forms of three
numbers, wherein the last part is interpreted as a 16-bit quantity
and placed in the right-most two bytes of the network address (e.g.,
a Class B network). Likewise, a dotted form of two numbers means
that the last part is interpreted as a 24-bit quantity and placed in
the right-most three bytes of the network address (Class A), and a
single number (without dots) is interpreted as a 32-bit quantity and
stored directly in the network address. Adding further to the
confusion, some implementations allow each dotted part to be
interpreted as decimal, octal, or hexadecimal, as specified in the C
language (i.e., a leading 0x or 0X implies hexadecimal; a leading 0
implies octal; otherwise, the number is interpreted as decimal).
These additional IP address formats are not allowed in the URI syntax
due to differences between platform implementations.
A host identified by an IPv4 literal address is represented in
dotted-decimal notation (a sequence of four decimal numbers in the
range 0 to 255, separated by "."), as described in [RFC1123] by
reference to [RFC0952]. Note that other forms of dotted notation may
be interpreted on some platforms, as described in Section 7.4, but
only the dotted-decimal form of four octets is allowed by this
grammar.
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
Whenever a user inputs the identity of an Internet host, it SHOULD
be possible to enter either (1) a host domain name or (2) an IP
address in dotted-decimal ("#.#.#.#") form. The host SHOULD check
the string syntactically for a dotted-decimal number before
looking it up in the Domain Name System.
So in this light, the headline on this page is both right and wrong. 3098282570 is indeed a valid IPv4 address; it is within the range of a 32-bit unsigned integer. It's not required or recommended to be recognized as such in host name contexts, though, and http://3098282570/ is not a valid URI.
I don't care who someone is because I evaluate individual statements on their own merits. In Rachel's own statement, she just learned "why this worked" "the last time it came up on HN". I got my first modem in 1985 (have you noticed my username?) and been in IT for longer than most HN users have been alive. But feel free to tell me how I don't have a right to discuss something because I'm correcting the Rachel Kroll.
Agreed. I read that statement with the same disregard. Unless she wrote the entirety of the ip stack specification, the argument is moot. Not one single person does or can know every piece of the technology puzzle. This amounts to calling me stupid for using gnome because Linus likes KDE, or more recently vice versa.
rachelbythebay didn't say it only applies to one implementation. She said it was implementation specific. A subtle distinction, but she's correct. Just because something is fundamentally a 32-bit number, that doesn't automatically mean that all possible representations of that number will be converted to it. They have to be implemented to do so.
At best, you seem to be picking nits. More likely though I think you just have a very surface level understanding of what is going on here.
The bottom line is that, as I said already, an IPv4 address is a 32 bit number. It's also true that various tools that communicate with IP addresses utilize different methods to arrive at the underlying 32 bit number. But it's not right to say that "this only applies to systems using ping from iptools and glibc" as the article you linked says. Many of these "tricks" worked in all manner of operating systems and applications. I was discussing many of them in IRC using Windows 3.1 and Trumpet Winsock before 1994.
Again, the bottom line is that an IPv4 IP address is a 32 bit number and there are dozens of ways that various applications allow you to arrive at that number. It's silly for an article or someone quoting it to attempt to say it only applies to one implementation.