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

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

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

Предыдущее
От: "Thomas G. Lockhart"
Дата:
Сообщение: Re: [HACKERS] dynamic libraries
Следующее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: [HACKERS] Dumping of views -- done!