Обсуждение: Re: inet/cidr/bind
> From: darcy@druid.net (D'Arcy J.M. Cain)
> Date: Sun, 11 Oct 1998 07:17:58 -0400 (EDT)
>
> Thus spake Paul A Vixie
> > 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.
>
> Is there also agreement on the use of -1 to mean unspecified netmask?
ok. this means we have to return octets and use an argument for *bits.
> How about the optional input form h.h.h.h:m.m.m.m to specify netmask?
i'd rather avoid this, since cidr does not allow noncontiguous netmasks
and i'd rather not create another error return case unless it's REALLY
important. is it? as currently specified:
/*
* static int
* inet_cidr_pton(af, src, dst, size, *bits)
* convert network address from presentation to network format.
* accepts hex octets, hex strings, decimal octets, and /CIDR.
* "size" is in bytes and describes "dst". "bits" is set to the
* /CIDR prefix length if one was specified, or -1 otherwise.
* return:
* number of octets consumed of "dst", or -1 if some failure occurred
* (check errno). ENOENT means it was not a valid network address.
* note:
* 192.5.5.1/28 has a nonzero host part, which means it isn't a network
* as called for by inet_net_pton() but it can be a host address with
* an included netmask.
* author:
* Paul Vixie (ISC), October 1998
*/
int
inet_net_pton(int af, const char *src,
void *dst, size_t size,
int *bits)
{
switch (af) {
case AF_INET:
return (inet_cidr_pton_ipv4(src, dst, size, bits));
default:
errno = EAFNOSUPPORT;
return (-1);
}
}
> > 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.
>
> And if bits is -1 then don't print the /NN part, right?
ok. here's what that looks like, for comments before i write it:
/*
* char *
* inet_cidr_ntop(af, src, len, bits, dst, size)
* convert network address from network to presentation format.
* generates "/CIDR" style result unless "bits" is -1.
* return:
* pointer to dst, or NULL if an error occurred (check errno).
* note:
* 192.5.5.1/28 has a nonzero host part, which means it isn't a network
* as called for by inet_net_pton() but it can be a host address with
* an included netmask.
* author:
* Paul Vixie (ISC), October 1998
*/
char *
inet_cidr_ntop(int af, const void *src, size_t len, int bits,
char *dst, size_t size)
{
switch (af) {
case AF_INET:
return (inet_cidr_ntop_ipv4(src, len, bits, dst, size));
default:
errno = EAFNOSUPPORT;
return (NULL);
}
}
> From: darcy@druid.net (D'Arcy J.M. Cain)
> Date: Sun, 11 Oct 1998 07:40:41 -0400 (EDT)
>
> Thus spake Paul A Vixie
> > 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.
>
> I have another question. What is the point of "used?" Can't I just
> assume 4 octets for ipv4 and 6 for ipv6? Can I set it to NULL if I
> don't care about the value?
we probably could have done this until we had to return octets and fill *used
with the bits. but more importantly, i think we should still only touch the
octets in *dst that are nec'y. this is consistent with the _ntop() as well.
> From: darcy@druid.net (D'Arcy J.M. Cain)
> Date: Sun, 11 Oct 1998 20:22:25 -0400 (EDT)
>
> ... [One] more thing. I built my stuff on the assumption that the
> inet_cidr_ntop function returned char *, not int. I assume that was
> just an error in your message. In fact, here is the way I added the
> prototypes to builtins.h.
Yes.
> char *inet_cidr_ntop(int af, const void *src, size_t len, int bits, char *dst, size_t size);
> int inet_cidr_pton(int af, const void *src, void *dst, size_t size, int *used);
>
> Is this what you had in mind?
Yes. But note that as now proposed, inet_cidr_pton() returns octets not bits
as earlier proposed, and sets *used to the bits not the octets as earlier
proposed.
If there are no further comments?
(In case y'all are wondering, this is how BIND's other library functions
got specified, though the driving application wasn't PostGreSQL last time.)
Thus spake Paul A Vixie
> > From: darcy@druid.net (D'Arcy J.M. Cain)
> > How about the optional input form h.h.h.h:m.m.m.m to specify netmask?
>
> i'd rather avoid this, since cidr does not allow noncontiguous netmasks
> and i'd rather not create another error return case unless it's REALLY
> important. is it? as currently specified:
Not that important I think. It was just a leftover though from earlier
discussions. I just wanted to make sure we considered it. The issue
of the extra error return came up back then too.
> /*
> * static int
> * inet_cidr_pton(af, src, dst, size, *bits)
> * convert network address from presentation to network format.
> * accepts hex octets, hex strings, decimal octets, and /CIDR.
> * "size" is in bytes and describes "dst". "bits" is set to the
> * /CIDR prefix length if one was specified, or -1 otherwise.
> * return:
> * number of octets consumed of "dst", or -1 if some failure occurred
> * (check errno). ENOENT means it was not a valid network address.
So if it is a network we don't have to fill the whole structure, right?
What happens on these calls?
inet_cidr_pton(af, "192.5/16", dst, sizeof dst, &bits);
inet_cidr_pton(af, "192.5/24", dst, sizeof dst, &bits);
inet_cidr_pton(af, "192.5.5.1/16", dst, sizeof dst, &bits);
I'm guessing that the return and bits for each would be (2, 16), (3, 24)
and (4, 16). Is that correct or since they are all ipv4 addresses would
the size always be 4?
> * note:
> * 192.5.5.1/28 has a nonzero host part, which means it isn't a network
> * as called for by inet_net_pton() but it can be a host address with
> * an included netmask.
> * author:
> * Paul Vixie (ISC), October 1998
> */
> int
> inet_net_pton(int af, const char *src,
inet_cidr_pton?
> ok. here's what that looks like, for comments before i write it:
>
> /*
> * char *
> * inet_cidr_ntop(af, src, len, bits, dst, size)
> * convert network address from network to presentation format.
> * generates "/CIDR" style result unless "bits" is -1.
Sounds right.
> > I have another question. What is the point of "used?" Can't I just
> > assume 4 octets for ipv4 and 6 for ipv6? Can I set it to NULL if I
> > don't care about the value?
>
> we probably could have done this until we had to return octets and fill *used
> with the bits. but more importantly, i think we should still only touch the
> octets in *dst that are nec'y. this is consistent with the _ntop() as well.
Does this mean we need to add a size element to the inet structure?
> Yes. But note that as now proposed, inet_cidr_pton() returns octets not bits
> as earlier proposed, and sets *used to the bits not the octets as earlier
> proposed.
OK. I'll wait till your stuff has been added to fix my stuff. That way
I can test it and send in the final changes once (hopefully.)
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
> So if it is a network we don't have to fill the whole structure, right?
right.
> What happens on these calls?
>
> inet_cidr_pton(af, "192.5/16", dst, sizeof dst, &bits);
> inet_cidr_pton(af, "192.5/24", dst, sizeof dst, &bits);
> inet_cidr_pton(af, "192.5.5.1/16", dst, sizeof dst, &bits);
>
> I'm guessing that the return and bits for each would be (2, 16), (3, 24)
> and (4, 16). Is that correct or since they are all ipv4 addresses would
> the size always be 4?
yes. :-). i mean, the former. {2,16}, {3,24}, and {4,16}. ipv4 is the
family of the address but does not dictate the size of the prefix. i still
don't want to touch octets which aren't specified, any more than i would
want to emit them in _ntop(). but that's my preference speaking -- what is
yours?
> > int
> > inet_net_pton(int af, const char *src,
>
> inet_cidr_pton?
oops, yeah. you can see where i copied this stuff from.
> Does this mean we need to add a size element to the inet structure?
i think so, yes.
Thus spake Paul A Vixie
> > inet_cidr_pton(af, "192.5/16", dst, sizeof dst, &bits);
> > inet_cidr_pton(af, "192.5/24", dst, sizeof dst, &bits);
> > inet_cidr_pton(af, "192.5.5.1/16", dst, sizeof dst, &bits);
> >
> > I'm guessing that the return and bits for each would be (2, 16), (3, 24)
> > and (4, 16). Is that correct or since they are all ipv4 addresses would
> > the size always be 4?
>
> yes. :-). i mean, the former. {2,16}, {3,24}, and {4,16}. ipv4 is the
> family of the address but does not dictate the size of the prefix. i still
> don't want to touch octets which aren't specified, any more than i would
> want to emit them in _ntop(). but that's my preference speaking -- what is
> yours?
Well, I don't mind filling in the whole structure. It would simplify
a few things and we wouldn't need to add a size element to the structure.
The network function will output it correctly, I think.
inet_network_with_bits('192.5/16') => '192.5/16'
inet_network_with_bits('192.5.5.1/16') => '192.5/16'
inet_network_with_bits('192.5/24') => '192.5.0/16'
Does this seem right?
> > Does this mean we need to add a size element to the inet structure?
> i think so, yes.
Unless we zero-pad, right?
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
> From: darcy@druid.net (D'Arcy J.M. Cain)
> Date: Tue, 13 Oct 1998 12:58:03 -0400 (EDT)
>
> Well, I don't mind filling in the whole structure. It would simplify
> a few things and we wouldn't need to add a size element to the structure.
ok.
> The network function will output it correctly, I think.
>
> inet_network_with_bits('192.5/16') => '192.5/16'
> inet_network_with_bits('192.5.5.1/16') => '192.5/16'
> inet_network_with_bits('192.5/24') => '192.5.0/16'
>
> Does this seem right?
for networks, yes.
> > > Does this mean we need to add a size element to the inet structure?
> > i think so, yes.
>
> Unless we zero-pad, right?
ok. here's the current proposal. any further comments?
/*
* char *
* inet_cidr_ntop(af, src, bits, dst, size)
* convert network address from network to presentation format.
* generates "/CIDR" style result unless "bits" is -1. "src"'s
* size is determined from its "af".
* return:
* pointer to dst, or NULL if an error occurred (check errno).
* note:
* 192.5.5.1/28 has a nonzero host part, which means it isn't a network
* as called for by inet_net_pton() but it can be a host address with
* an included netmask.
* author:
* Paul Vixie (ISC), October 1998
*/
char *
inet_cidr_ntop(int af, const void *src, int bits, char *dst, size_t size) {
switch (af) {
case AF_INET:
return (inet_cidr_ntop_ipv4(src, bits, dst, size));
default:
errno = EAFNOSUPPORT;
return (NULL);
}
}
...
/*
* int
* inet_cidr_pton(af, src, dst, *bits)
* convert network address from presentation to network format.
* accepts hex octets, hex strings, decimal octets, and /CIDR.
* "dst" is assumed large enough for its "af". "bits" is set to the
* /CIDR prefix length if one was specified, or -1 otherwise.
* return:
* 0 on success, or -1 if some failure occurred (check errno).
* ENOENT means it was not a valid network address.
* note:
* 192.5.5.1/28 has a nonzero host part, which means it isn't a network
* as called for by inet_net_pton() but it can be a host address with
* an included netmask.
* author:
* Paul Vixie (ISC), October 1998
*/
int
inet_cidr_pton(int af, const char *src, void *dst, int *bits) {
switch (af) {
case AF_INET:
return (inet_cidr_pton_ipv4(src, dst, bits));
default:
errno = EAFNOSUPPORT;
return (-1);
}
}
Thus spake Paul A Vixie
> > The network function will output it correctly, I think.
> >
> > inet_network_with_bits('192.5/16') => '192.5/16'
> > inet_network_with_bits('192.5.5.1/16') => '192.5/16'
> > inet_network_with_bits('192.5/24') => '192.5.0/16'
> >
> > Does this seem right?
>
> for networks, yes.
Hmm. It _is_ the network function I was talking about. The same inputs
whould give the following results.
Input Network (with) Network (without) Host Broadcast
192.5/16 192.5/16 192.5 192.5.0.0 192.5.255.255
192.5.5.1/16 192.5/16 192.5 192.5.0.0 192.5.255.255
192.5/24 192.5.0/16 192.5.0 192.5.0.0 192.5.0.255
Of course, you wouldn't expect the first and last to have the host function
applied to it. They are probably in a field used to store networks.
> ok. here's the current proposal. any further comments?
>
> /*
> * char *
> * inet_cidr_ntop(af, src, bits, dst, size)
> * convert network address from network to presentation format.
> * generates "/CIDR" style result unless "bits" is -1. "src"'s
> * size is determined from its "af".
And size is the available space in dst, right? Perfect.
> /*
> * int
> * inet_cidr_pton(af, src, dst, *bits)
> * convert network address from presentation to network format.
> * accepts hex octets, hex strings, decimal octets, and /CIDR.
> * "dst" is assumed large enough for its "af". "bits" is set to the
> * /CIDR prefix length if one was specified, or -1 otherwise.
This sounds bang-on to me. How soon before your functions are in the
tree? I'll start modifying my code based on this but I won't send it
in until I have tested it against your functions.
By George! I think we've got it. :-)
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
> This sounds bang-on to me. How soon before your functions are in the > tree? I'll start modifying my code based on this but I won't send it > in until I have tested it against your functions. I have not seen any patch yet. Paul, was your earlier posting supposed to be applied? If so, let me know. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
darcy@druid.net (D'Arcy J.M. Cain) writes: > By George! I think we've got it. :-) Yup! Great work, guys! I like what I see in the tree so far -- just waiting for the transition to complete so I can use my network data again! :-) -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
> > This sounds bang-on to me. How soon before your functions are in the > > tree? I'll start modifying my code based on this but I won't send it > > in until I have tested it against your functions. > > I have not seen any patch yet. Paul, was your earlier posting supposed > to be applied? If so, let me know. no. i will supply new source files to replace and augment the bind-based source files in your current pool. (i'll want the new $Id:$'s for example.)
> > By George! I think we've got it. :-)
> Yup! Great work, guys! I like what I see in the tree so far -- just
> waiting for the transition to complete so I can use my network data
> again! :-)
I've forgotten who volunteered to write or update docs for this. I need
to freeze the User's Guide fairly soon (~4 days?), and need to add a
mention of the CIDR data type in "datatype.sgml".
I assume that the README.inet which is currently in the tree is not an
accurate document now? I would be happy to transcribe a plain text
description into sgml, and would then expect last-minute updates to
happen in the sgml source rather than the original plain text. OK?
- Tom
> > > By George! I think we've got it. :-) > > Yup! Great work, guys! I like what I see in the tree so far -- just > > waiting for the transition to complete so I can use my network data > > again! :-) > > I've forgotten who volunteered to write or update docs for this. I need > to freeze the User's Guide fairly soon (~4 days?), and need to add a > mention of the CIDR data type in "datatype.sgml". > > I assume that the README.inet which is currently in the tree is not an > accurate document now? I would be happy to transcribe a plain text > description into sgml, and would then expect last-minute updates to > happen in the sgml source rather than the original plain text. OK? There were no volunteers, and in fact, it is still changing. When it is done, one of the few people who have followed the features will have to write something up. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026