ipaddr-py: New IPv4 netmask/hostmask parser.

The previous code checks each octet separately, and then checks if
the sequence of octets is nonincreasing.  This is insufficient, because
it allows nonsensical inputs like "255.128.128.0".

The previous code also only partially handles hostmasks (inverted netmasks).
"0.255.255.255" becomes /8, but 0.15.255.255 is rejected.

The solution is to disregard octets, and interpret the address as a
single sequence of bits.

Note that this could be trivially extended to support IPv6 netmasks and
hostmasks, but those are non-standard.

I've also made the CIDR parser more strict, so it rejects anything that's
not not a decimal digit, like /+24

Added:
- _prefix_from_prefix_string: Parse a number, with bounds checking.
- _prefix_from_ip_string: Parse IPv4 netmask/hostmask string.

Improved:
- _prefix_from_ip_int: Only accept inputs with the bit sequence /1*0*/.

Removed:
- _ip_string_from_prefix
- _is_hostmask
- _is_valid_netmask

[Peter Moody, 2013-09-20 21:33:39]

Thanks much for doing this.

If it's not too much trouble, could you include some information on the bugs in
the existing parser?

[Peter Moody, 2013-09-20 21:33:45]

https://codereview.appspot.com/13745043/diff/1/trunk/ipaddr.py
File trunk/ipaddr.py (right):

https://codereview.appspot.com/13745043/diff/1/trunk/ipaddr.py#newcode922
trunk/ipaddr.py:922: # Try matching a netmask (1*0*).  Note that the two
ambiguous cases
(1*0*). 

I'm having a hard time understanding what that's signifying. Is that a regular
expression?

https://codereview.appspot.com/13745043/diff/1/trunk/ipaddr_test.py
File trunk/ipaddr_test.py (right):

https://codereview.appspot.com/13745043/diff/1/trunk/ipaddr_test.py#newcode458
trunk/ipaddr_test.py:458: 
I'm not sure I understand the purpose of the tests between 430-455. It looks
like a series of

  addr1 = '0.0.0.0/%d'
  addr2 = '0.0.0.0/%d'

  assertEqual(addr1,addr2)

I presume I'm missing something more subtle?

https://codereview.appspot.com/13745043/diff/1/trunk/ipaddr_test.py#newcode461
trunk/ipaddr_test.py:461: # netmasks are rarely seen in the wild.
nit, I think it's all but expressly prohibited.

http://tools.ietf.org/html/rfc4291#section-2.3

[pmarks, 2013-09-20 22:36:35]

https://codereview.appspot.com/13745043/diff/1/trunk/ipaddr.py
File trunk/ipaddr.py (right):

https://codereview.appspot.com/13745043/diff/1/trunk/ipaddr.py#newcode922
trunk/ipaddr.py:922: # Try matching a netmask (1*0*).  Note that the two
ambiguous cases
On 2013/09/20 21:33:45, Peter Moody wrote:
> (1*0*). 
> 
> I'm having a hard time understanding what that's signifying. Is that a regular
> expression?

Clarified the regexp notation.

https://codereview.appspot.com/13745043/diff/1/trunk/ipaddr_test.py
File trunk/ipaddr_test.py (right):

https://codereview.appspot.com/13745043/diff/1/trunk/ipaddr_test.py#newcode458
trunk/ipaddr_test.py:458: 
On 2013/09/20 21:33:45, Peter Moody wrote:
> I'm not sure I understand the purpose of the tests between 430-455. It looks
> like a series of
> 
>   addr1 = '0.0.0.0/%d'
>   addr2 = '0.0.0.0/%d'
> 
>   assertEqual(addr1,addr2)
> 
> I presume I'm missing something more subtle?

Well, at least in the IPv4 case, we're generating and re-parsing every valid
netmask and hostmask; the old hostmask code would have failed here.  The IPv6
tests are less interesting because CIDR is so simple.

https://codereview.appspot.com/13745043/diff/1/trunk/ipaddr_test.py#newcode461
trunk/ipaddr_test.py:461: # netmasks are rarely seen in the wild.
On 2013/09/20 21:33:45, Peter Moody wrote:
> nit, I think it's all but expressly prohibited.
> 
> http://tools.ietf.org/html/rfc4291#section-2.3

Done.

[Peter Moody, 2013-09-21 16:32:52]

lgtm

[Peter Moody, 2013-09-21 17:09:57]

On 2013/09/21 16:32:52, Peter Moody wrote:
> lgtm

applied in 669c0368e3e4	.

thanks again!

[pmarks, 2013-10-02 03:42:14]

On 2013/09/21 17:09:57, Peter Moody wrote:
> On 2013/09/21 16:32:52, Peter Moody wrote:
> > lgtm
> 
> applied in 669c0368e3e4	.
> 
> thanks again!

I just noticed that a similar patch was proposed in this Python bug:
http://bugs.python.org/issue18805