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: > > On 24.11.2013 19:43, Özkan KIRIK wrote: > > > Hi, > > > > > > I tested patch. This patch solves, ipfw table 1 add 4899 > > Ok. So I'll commit this fix soon. > > > > > > But, ipfw table 1 add 10.2.3.01 works incorrectly. > > > output is below. > > > # ./ipfw table 1 flush > > > # ./ipfw table 1 add 10.2.3.01 > > inet_pton() does not recognize this as valid IPv4 address, so it is > > treated as usigned unteger key. It looks like this behavior is mentioned > > in STANDARDS section. > > > # ./ipfw table 1 list > > > 0.0.0.10/32 0 > > 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. -- Ian _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[email protected]"
