Hey all,
As the subject says, APNIC was allocated 14/8 and 223/8 today... which does seems a little close after 1/8 and 27/8 in January 2010 - since 1/8 hasn't started, I'm surprised about the new ones.
Not sure why I haven't seen any announcements about it... just thought I'd break the news...
...Skeeve
a message of 37 lines which said:
As the subject says, APNIC was allocated 14/8 and 223/8 today...
Actually, it was a few days ago.
Not sure why I haven't seen any announcements about it...
There have been announcements (here a mail from APNIC on the Sanog
mailing list).
Sunny,
Please be careful about how you write this. "014" is formally an octal
representation, and what you've written there actually means that APNIC has
received 12/8 (= octal 014).
Nick
Nick,
My eyebrow raised at the leading zero as well, but I'd call it
ambiguous. 0x14 is unambiguously decimal 20, but 014 is only
unambiguous in a context that defines leading zero as implying octal.
For a C program relying on the runtime to convert text to numeric
representation, it depends. sscanf("%d", &myint) will convert 014 to
decimal 14, "%i" gets decimal 12.
I personally hunt down and kill %i and other octal-assuming code when
I see it, except where octal is conventional. To my eyes, 0xFF (or
FF) screams "all bits lit" while 0377 (or 377) only hesitantly clears
its throat. Moreover, I assume computers will be used by people who
have never had reason to believe a leading zero implies base 8, and I
find no joy in forcing them to learn that quirk of computing history.
Take care,
Dave Hart
Note that such a context is inet_ntoa(), at least on BSD-based machines I have handy.
From inet(3):
All numbers supplied as ``parts'' in a `.' notation may be decimal,
octal, or hexadecimal, as specified in the C language (i.e., a leading 0x
or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other-
wise, the number is interpreted as decimal).
Given the popularity of Octal in address nomenclature in 2010 this seems like a small problem for mail to NANOG. However, if the practice extends to use in contexts which might be machine-readable (e.g. in text files which are auto-curl(1)d out of cron to build filters) then there is potential for hilarity.
Joe
On 14/04/2010 08:06, Srinivas Chendi <sunny@apnic.net> wrote to SANOG:
014/8
223/8
Sunny,
Please be careful about how you write this. "014" is formally an octal
representation, and what you've written there actually means that APNIC has
received 12/8 (= octal 014).Nick
Nick,
My eyebrow raised at the leading zero as well, but I'd call it
ambiguous. 0x14 is unambiguously decimal 20, but 014 is only
unambiguous in a context that defines leading zero as implying octal.
For a C program relying on the runtime to convert text to numeric
representation, it depends. sscanf("%d", &myint) will convert 014 to
decimal 14, "%i" gets decimal 12.I personally hunt down and kill %i and other octal-assuming code when
I see it, except where octal is conventional. To my eyes, 0xFF (or
FF) screams "all bits lit" while 0377 (or 377) only hesitantly clears
its throat. Moreover, I assume computers will be used by people who
have never had reason to believe a leading zero implies base 8, and I
find no joy in forcing them to learn that quirk of computing history.
On an up to date OSX install (and Centos linux and FreeBSD)
(15:23:17 <~>) 0 $ ping 014.0.0.1
PING 014.0.0.1 (12.0.0.1): 56 data bytes
Request timeout for icmp_seq 0
From windows 2003 servert
C:\Documents and Settings\Administrator>ping 014.0.0.01
Pinging 12.0.0.1 with 32 bytes of data:
wget (on linux and freebsd)
(15:26:02 <~>) 0 $ wget 014.0.0.1
--2010-04-14 15:26:06-- http://014.0.0.1/
Connecting to 014.0.0.1|12.0.0.1|:80...
Oddly on OSX it doesnt take it as octal
(15:27:30 <~>) 130 $ wget 014.0.0.1
--2010-04-14 15:27:31-- http://014.0.0.1/
Connecting to 014.0.0.1 (014.0.0.1)|14.0.0.1|:80...
When it comes to IP addresses, its not history, its important 
Vince
On 14/04/2010 08:06, Srinivas Chendi <sunny@apnic.net> wrote to SANOG:
014/8
223/8
Sunny,
Please be careful about how you write this. "014" is formally an octal
representation, and what you've written there actually means that APNIC has
received 12/8 (= octal 014).Nick
Nick,
My eyebrow raised at the leading zero as well, but I'd call it
ambiguous. 0x14 is unambiguously decimal 20, but 014 is only
unambiguous in a context that defines leading zero as implying octal.
For a C program relying on the runtime to convert text to numeric
representation, it depends. sscanf("%d", &myint) will convert 014 to
decimal 14, "%i" gets decimal 12.I personally hunt down and kill %i and other octal-assuming code when
I see it, except where octal is conventional. To my eyes, 0xFF (or
FF) screams "all bits lit" while 0377 (or 377) only hesitantly clears
its throat. Moreover, I assume computers will be used by people who
have never had reason to believe a leading zero implies base 8, and I
find no joy in forcing them to learn that quirk of computing history.
On an up to date OSX install (and Centos linux and FreeBSD)
(15:23:17 <~>) 0 $ ping 014.0.0.1
PING 014.0.0.1 (12.0.0.1): 56 data bytes
Request timeout for icmp_seq 0From windows 2003 servert
C:\Documents and Settings\Administrator>ping 014.0.0.01
Pinging 12.0.0.1 with 32 bytes of data:wget (on linux and freebsd)
(15:26:02 <~>) 0 $ wget 014.0.0.1
--2010-04-14 15:26:06-- http://014.0.0.1/
Connecting to 014.0.0.1|12.0.0.1|:80...Oddly on OSX it doesnt take it as octal
(15:27:30 <~>) 130 $ wget 014.0.0.1
--2010-04-14 15:27:31-- http://014.0.0.1/
Connecting to 014.0.0.1 (014.0.0.1)|14.0.0.1|:80...When it comes to IP addresses, its not history, its important
I think it is important form us to recognize and accept that this is 2010.
The Constitution means what ever the speaker needs for it to mean, or
can be dismissed outright.
014 means what ever the speaker needs for it to mean.....
It is the duty and responsibility of the hearer (or reader) to figure
out how it applies to them for the moment.
Standards and agreements on protocol are so eighteenth century.
Vince
Take care,
Dave Hart
Dark Ages Larry
Good point. In most of these classic utility contexts, octal is
generally accepted. 32-bit unsigned decimal representation has
provided obfuscation for fun and profit in HTTP URIs. I'm sure you
can find some software that still accepts it, and some that doesn't.
For me, with no proxy, Chrome and IE both accept a non-dotted numeric
IPv4 URI, but rewrite it in the address bar to the familiar dotted
quad format. FireFox shows an error page that appears equivalent to:
<h1>Bad Request (Invalid Hostname)</h1>
FireFox is probably violating some spec. Thankfully.
Cheers,
Dave Hart
But note Theos reply about just this paragraph:
"Yes, we should fix the manual page. Single Unix is wrong in this regard."
-- http://kerneltrap.org/mailarchive/openbsd-bugs/2009/6/6/5882713/thread
Also this from two months ago:
http://www.merit.edu/mail.archives/nanog/msg05062.html
Don't expect non-canonical IP address formats to work. Because they often don't. And you just might get silent errors.
This is a historical issue with inet_aton(). See http://tools.ietf.org/html/draft-main-ipaddr-text-rep-00 for more details on the history behind this.
Firefox bug 554596 addresses this problem.
-- N.