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@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026