From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 16:36:50 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FFFE1FE for ; Mon, 25 Nov 2013 16:36:50 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 55C65261F for ; Mon, 25 Nov 2013 16:36:50 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vkz9V-00085G-6a; Mon, 25 Nov 2013 16:36:49 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rAPGakci004729; Mon, 25 Nov 2013 09:36:46 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18Ca292/Y7P13P8909OVAtU Subject: Re: ipfw table add problem From: Ian Lepore To: Ben Morrow In-Reply-To: <20131125154110.GA32738@anubis.morrow.me.uk> References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <20131125154110.GA32738@anubis.morrow.me.uk> Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Nov 2013 09:36:46 -0700 Message-ID: <1385397406.1220.10.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 16:36:50 -0000 On Mon, 2013-11-25 at 15:41 +0000, Ben Morrow wrote: > Quoth Ian Lepore : > > On Mon, 2013-11-25 at 15:30 +1100, Ian Smith wrote: > > > On Sun, 24 Nov 2013 23:56:14 +0400, Alexander V. Chernikov wrote: > > > > > > I'm wondering if "so don't do that" is really sufficient to deal with > > > this? If it's not recognised as a valid address, shouldn't it fail to > > > add anything, with a complaint? I don't see how a string containing > > > dots can be seen as a valid unsigned integer? > > > > It's still not clear to me that inet_pton() is doing the right thing. > > Per the rfc cited earlier in the thread, it's not supposed to interpret > > the digits as octal or hex -- they are specifically declared to be > > decimal numbers. There's nothing invalid about "01" as a decimal > > number. The fact that many of us have a C-programming background and > > tend to think of leading-zero as implying octal doesn't change that. > > OTOH having inet_pton and inet_aton treat 10.0.0.010 as different > addresses would be rather confusing. But that's exactly the situation we have right now. If inet_aton() or inet_addr() is in use in a given utility you get one behavior, and if inet_pton() is is use you get a different behavior. Right now that different behavior is also incorrect (unless there are some other words in a standard somewhere that specifically forbid leading zeros in the decimal components). -- Ian