Re: [HACKERS] Re: inet/cidr/bind

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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: TCL_LIB, TCL_INCDIR removed
Следующее
От: darcy@druid.net (D'Arcy J.M. Cain)
Дата:
Сообщение: Re: [HACKERS] Permissions not working?