> 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.