Additional IP support

[JohnMcHugh]

libcork's support for the IP address types is limited. Additional operations are needed. Wherever the generic ip is used, assume ipv4,6 specific versions, as well, if appropriate.

Internal (cork, cork)

int cork_ip_cmp(const struct cork_ip *addr1, const struct cork_ip *addr2)

returns -1, 0, 1 for <, ==, >

void cork_ip_and_mask(struct cork_ip *addr1, const struct cork_ip *mask)
void cork_ip_or_mask(struct cork_ip *addr1, const struct cork_ip *mask)

and or or the specified mask to the address. The generic version could be created, but would need to raise an error if the versions of the operands were different. In addition to masking by address form masks, masking by cidr prefix would be useful.

int cork_ip_to_prefix(struct cork_ip *addr1, const int cidr_prefix) 

This returns error codes if the prefix is out of range for the ip or if the masking removed bits from the address. Whether the later is an error or informative depends on the intended use. If one is testing to see if the address is a legitimate prefix for the given cidr size, removing bits is an error. If one is trying to create a prefix address, it is not. Might want to separate this into 2 families
the form above that only checks to see if the prefix is appropriate and another, say

bool cork_ip_is_prefix(const struct cork_ip *addr1, const int cidr_prefix)

interface (cork <-> other)

void cork_ipv4_from_int( struct cork_ipv4 *addr1,  const uint32_t ip_int)
void cork_ipv4_to_int( const struct cork_ipv4 *addr1,  uint32_t  *ip_int)

Yes, these can be composed from the existing functions, but burying the endianess is desirable. As 128 bit machines become available similar, ipv6 versions will be desirable. We often find data files with ips represented as integers for a variety of reasons.

Other operations may also be desirable, for example, in building the bitset version of the ipset code, I needed operations that would split an ipv4 address treated as a 32 bit string with bit 0 on the right, bit 31 on the left into 4 integer fields, bits 31-23 (/9 prefix), bits 22-14 (/18 within a given /9), 13-5 (/27 within a given /18), and 4-0 (address within a /27). I did this accessing the individual bytes of the cork_ipv4 array, but a general mechanism might be useful. Note that all but the last require accessing 2 bytes, possibly masking and shifting each one, then combining the results. For IPv4, the computation would be simpler if performed on the native int representation of the address, but some careful performance analysis might be required to determine whether the time saved this way would pay for conversion to native order each time.

[dcreager]

@dcreager CCing myself