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

> Originally I thought we were calling 'a' the cidr type and 'b' the inet
> type hence my confusion.  I still think that that is the better but since
> we have working code and it is already named, I guess we should go with it.

This sounds like consensus to me.  Bruce said the same.

> > > So host only - no additional information carried in the type?
> > 
> > That would be my preference.  But as it would be the same underlying type,
> > it would be possible to ask for all supernet INETs of some IHOST -- the
> > supernet/subnet comparison functions would be inherently polymorphic.  I've
> > already got an application in mind that would benefit from this
> > polymorphism.
> 
> You think it should be a differnt type then?  You can do it with one if
> you use /32 for hosts, right?  In fact, make a naked ip imply /32 for
> INET type but /-1 for CHOST type (if we go with it.)

In IHOST as I proposed it, it would have the same on-disk format as INET,
but with a fixed /32 and with different parsing and printing functions:
the parser would object unless all four octets and no /## was specified,
and the printer would just print the octets and elide the /32.  There are
functions in BIND, i.e., inet_pton() and inet_ntop(), which do that kind
of parsing and printing.

> In fact, forget the -1 idea.  Default both types to /32 and never print
> the bits for the CHOST type.  That simplifies the calculations.

If we're never printing the bits for CHOST, it's not different from IHOST?

> > Is there no way to accomplish this without efficiency loss using a pair of
> > IHOSTs, one for the host address and one for the netmask?
> 
> It becomes messy.  In fact, I would use an integer for the netmask in that
> situation.

"Messy" is not as strong a concern as performance, though, is it?  If the
only time we need a host address and a netmask together is when a Radius
server using an SQL backend had to do some string arithmetic before sending
the Radius reply, then that's not as compelling an argument as it might be.