Re: INET/CIDR types

This whole discussion is quite silly guys.

It is quite reasonable to have ability to split CIDR net into two pieces:
the network and the bitshift. Second one is already possible, the first
one can be accomplished by having functions to convert a cidr/inet to int8
(not int4 because of sign thing), and back.

Its also very easy to implement ;)

This will actually come very useful for many applications. Something I'm
working on now (allocation of 'most appropriate' block) requires ability
to split a netblock into two, which could be most easily accomplished
using int8 math. (net::int8+2^(netmask(net)-1)).

Now, patch anyone? :)
-alex
On Tue, 25 Jul 2000, Sevo Stille wrote:

> Larry Rosenman wrote:
> > 
> > The problem is NON-TECHNICAL people will be getting the output,
> > and they expect 4 octet output.
> 
> Well, but what are they going to do if they see, say, that 196.100.0.0
> is already allocated? Any CIDR net starting off on the .0 will have
> exactly the same 4 octet notation. That is, the above entry would only
> tell that there is some indeterminable number of addresses starting off
> 196.100.0.0 allocated, which could be anything between a measly /31 and
> a whopping big /16. To repeat: CIDR having no implicit netmask encoded
> in the class, there is no way of figuring out your allocation if you
> lose the explicit mask. Which presumably will cause considerable
> problems in a network allocation and tracking application!
>  
> > I really think that we should have a way to coerce a CIDR to
> > an INET, and then allow host().
> 
> There is no unique mapping of a CIDR network to a INET host address,
> except for the special case of /32. 
>  
> > Remember that I am dealing with $10/hour clerks.
> 
> Then given them a interface which makes the concept of CIDR obvious to
> them. Faking a classed notation is no way to go! IP v.4 being what it
> is, and registries being on the move to enforce CIDR more and more, they
> will inevitably encounter CIDR sooner or later, probably in a business
> critical way.  
>  
> > I really don't get the hostility to changing the OUTPUT format...
> 
> Anything broken that is added will sooner or later be used by somebody.
> Which means that it can't be fixed without breaking some applications.
> That alone should be a good enough reason not to introduce any broken
> notions intentionally.
> 
> Sevo
> 
>