Re: [HACKERS] Re: inet/cidr/bind
От | Paul A Vixie |
---|---|
Тема | Re: [HACKERS] Re: inet/cidr/bind |
Дата | |
Msg-id | 199810131608.JAA07284@bb.rc.vix.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: inet/cidr/bind (darcy@druid.net (D'Arcy J.M. Cain)) |
Ответы |
Re: [HACKERS] Re: inet/cidr/bind
|
Список | pgsql-hackers |
> 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.
В списке pgsql-hackers по дате отправления: