Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This one caused a friend some headache when setting up a switched internet connection which had zero padded IP addresses in the configuration paper like so:

No matter how he tried to configure the Mac network stack, it just didn't work. But the GUI also didn't complain about errors.

I later found out that pinging these zero padded addresses in a terminal showed "unable to resolve" while pinging the same address without padded zeros ( vs. showed "unable to reach" which brought much light into this mysterium. Removing the useless zeros made everything work.

Is this a bug or a feature? I never experienced such strange behaviour before - no matter if I use the GUI or CLI to configure or test IP stuff.

share|improve this question
up vote 10 down vote accepted

Translation from a string to an address is usually performed by the POSIX function getaddrinfo(). This function first checks for a numeric IP address using inet_addr(), and if that fails it will then attempt to resolve the string as a domain name. inet_addr() interprets numbers with a leading 0 as octal, so for example 010 would become 8, and 019 would be an error (and would therefore be resolved as a domain name). The same behavior occurs on Linux and Solaris as well.

From getaddrinfo():

If the specified address family is AF_INET or AF_UNSPEC, address strings using Internet standard dot notation as specified in inet_addr() are valid.

From inet_addr():

All numbers supplied as parts in IPv4 dotted decimal notation may be decimal, octal, or hexadecimal, as specified in the ISO C standard (that is, a leading 0x or 0X implies hexadecimal; otherwise, a leading '0' implies octal; otherwise, the number is interpreted as decimal).

Note the address in parentheses:

$ ping
PING ( 56 data bytes
Request timeout for icmp_seq 0
share|improve this answer
Okay this pretty counterintuitive but could be useful. Still it does not explain why was unable to resolve while was unable to reach. Should've not both been unable to reach? – hurikhan77 Feb 15 '10 at 7:17
It just hit me like a flash: Speaking of octal numbers I remember that the original IP in question was something like - which is of course no valid number and thus an invalid host name. Amending my question... – hurikhan77 Feb 15 '10 at 7:25
I have updated my answer to answer the updated question. – mark4o Feb 15 '10 at 8:07
+1 and acc for the great explanation. Question remains why the system settings GUI of Mac OS does not interpret the numbers decimal as it should. However, the configuration paper of the ISP is simply plain wrong anyway. I tested against a Windows machine (because it's non-posix) which exhibits the same interpretation on CLI - it does however not do this on the GUI. – hurikhan77 Feb 15 '10 at 10:14
@hurikhan77 You got it. It's not a valid IP address, since 9 is not a legal octal digit, so the rule is to treat it as a host name. – David Schwartz Sep 16 '13 at 16:37

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.