[125397] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: APNIC Allocated 14/8, 223/8 today

daemon@ATHENA.MIT.EDU (Joe Abley)
Wed Apr 14 10:35:44 2010

From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <r2o85d954181004140545td3c7acc4iefb2def604161fc4@mail.gmail.com>
Date: Wed, 14 Apr 2010 10:35:10 -0400
To: davehart_gmail_exchange_tee@davehart.net
X-SA-Exim-Mail-From: jabley@hopcount.ca
Cc: NANOG <nanog@nanog.org>, Srinivas Chendi <sunny@apnic.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


On 2010-04-14, at 08:45, Dave Hart wrote:

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

Note that such a context is inet_ntoa(), at least on BSD-based machines =
I have handy.

=46rom 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=


home help back first fref pref prev next nref lref last post