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

Thus spake Paul A Vixie
> > Input            cidr output        inet output
> > =============    ================   ================
> > 192.63.91.234    192.63.91.234/32    192.63.91.234/32
> > 192.63.91        192.63.91/24       192.63.91.0/24
> > 192.63           192.63/16          192.63.0.0/16
> > 192              192/8              192.0.0.0/8
> > 
> > This look right to you, Paul?
> 
> no.  the last three inputs are not valid where a host address is expected.

Can you amplify?  Is it correct as far as cidr goes?  If so, I have no
problem making it an error for the inet type.  My thinking was based
on the earlier concept of having one type and accepting networks in it.
If we have the separate cidr type then I guess inet should always require
4 octets (until ipv6 anyway) and cidr should be used for networks.

How about something like 192.63.0.0/16?  Should that be an error under the
inet type since it is the network?  I am thinking not since technically
192.63.0.0 is a valid host under 192.63/16 although it is generally
avoided since there is still software that assumes that it is the
network or even the broadcast.

> > I understand why Paul needs his type but I think the inet type is
> > valuable too.  I think my suggestion above is a good compromise.
> 
> bigness of names doesn't matter.  applications matter.  i can see a use for
> both types, but they are inherently different types.  a host that has a

I agree although I did change my mind somewhat based on these discussions.

And besides:
   if (strlen("D'Arcy J.M. Cain") > strlen("Paul Vixie"))       printf("Who's the big name now?  :-)\n");

And look at all that StUdLy punctuation.  :-)

> a network only prints as many octets as the cidr width specifies, and these
> are the only required octets on input (though extra .0's can be specified).

Cool.  You answered another question I had before I asked it.

> > I think we are just about there.  If we go with my plan (completely
> > different functionality for now and fold it later) there should be
> > no API change later.  There will be code and catalogue changes but
> > they should be relatively painless.
> 
> so shall i test the inet_cidr_ functions and punt them on in?

Ok, before I have a reality shift, the inet_cidr_ functions are simply
the original inet_net_ functions renamed, right?

I so hate it when the universe does that stuttering thing.
-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.