ipfw table add problem

Ian Lepore ian at FreeBSD.org
Mon Nov 25 16:36:50 UTC 2013


On Mon, 2013-11-25 at 15:41 +0000, Ben Morrow wrote:
> Quoth Ian Lepore <ian at FreeBSD.org>:
> > 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




More information about the freebsd-stable mailing list