Re: inet/cidr/bind

my take on this is that (1) inet_net_pton() is definitely broken in that
it is willing to write one more byte of output than its arguments allow,
and (2) inet_net_{pton,ntop}() is not suitable for postgresql's use here.

i can fix (1) in bind 8.1.3, and postgresql already has it fixed in its
version of bind's library.

there is no way to fix (2) without an api change. we need, in order to
meet the stated needs of folks here who have uses for an inet-like type,
a way to have the prefix length be less than the size of the bitstring
being introduced. "16.1.0.2/28" was given as an example, that being a
way to give both a host address and its netmask on some wire. i've
wanted this functionality from time to time in the past and i can see
why for postgresql's purposes that's what should be provided for the
"inet" (or, given this change, more properly the "cidr") type.

but inet_net_ntop() only returns one thing (the prefix length) and the
caller is expected to know how many octets of mantissa were generated
based on this returned prefix length. i propose a new interface, which
would have a different name, a different argument list, and a different
use:

int
inet_cidr_pton(af, src, dst, size, int *used)

this would work very much the same as inet_net_pton() except for three
things: (1) nonzero trailing mantissas (host parts) would be allowed; (2)
the number of consumed octets of dst would be set into *used; and (3) there
would be absolutely no classful assumptions made if the pfxlen is not
specified in the input.

int
inet_cidr_ntop(ag, src, len, bits, dst, size)

this would work very much the same as inet_net_ntop() except that the
size (in octets) of src's mantissa would be given in the new "len" argument
and not imputed from "bits" as occurs now. "bits" would just be output
as the "/NN" at the end of the string, and would never be optional.

if this is agreeable, i'll code it up and submit it here for testing before
i push it out in bind 8.1.3. i really do agree with the functionality we've
drifted toward in this type -- if folks want to express the netmask of a
host address without getting in trouble for a nonzero host part that's
lost during parsing and storage, then they jolly well ought to be able to
do that.