| From: | Paul A Vixie <paul(at)vix(dot)com> |
|---|---|
| To: | pgsql-hackers(at)hub(dot)org |
| Subject: | Re: [HACKERS] Re: inet/cidr/bind |
| Date: | 1998-10-13 16:08:23 |
| Message-ID: | 199810131608.JAA07284@bb.rc.vix.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 1998-10-13 16:45:59 | TCL_LIB, TCL_INCDIR removed |
| Previous Message | Matthew N. Dodd | 1998-10-13 16:05:32 | Re: [HACKERS] dynamic libraries |