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 по дате отправления:

Предыдущее
От: "Matthew N. Dodd"
Дата:
Сообщение: Re: [HACKERS] dynamic libraries
Следующее
От: Bruce Momjian
Дата:
Сообщение: TCL_LIB, TCL_INCDIR removed