ipfw table add problem

[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:
>  > 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