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

> Thus spake Paul A Vixie
> > Since other people want to use this type differently, I propose that we make
> > it into two types: INET for host addresses and CIDR for network addresses.
> > Both can include /## to set a netmask if folks really don't like making the
> > address and netmask into two adjacent columns. But CIDR has to disallow
> > nonzero host-parts or it doesn't mean what I need it to mean.
>
> I am cool with this. In fact I think I mentioned earlier in the thread that
> this requirement (it was a theoretical possibility to me at the time) was
> the one reason why two different types might be required. OK so that
> means that, as I suggested, we need two underlying function sets, the
> inet_net_* ones and the inet_cidr_* ones (might be some efficiency
> possible if they are in the same source file and use some common
> routines) and the original inet.c file gets changed to cidr.c and
> turned into the cidr type. I'll take the existing inet.c as it exists
> on my system and submit it as the _new_ inet type.

Sorry, but I just have to ask. I am not sure what the issues are, but
it is possible to have them all be the same type. Have a netmask field
inside the type and a cidr field inside the type, and just use one of
them at a time for any given entry? Only one byte each, right? I sure
would like to avoid "type/function bloat". Also, could a RULE be
created to simulate the network restriction Paul requires?

Maybe it is clearer to have two types, with different purposes. I am
just asking, and if people are going to need functions to convert
between the two types, it may be worth merging them. I was thinking you
could display them differently based on which field they used.

This is all just a guess.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026