Hi Dave,
My apologies, I don't believe I sent a follow-up to this input.
Please see below.
Thank you,
Clay
On Wed, 21 Jul 2010, Dave Miner wrote:
On 07/21/10 08:13 PM, [email protected] wrote:
Reading the comments in the modification, this seems misguided. We
don't need to provide for a non-CIDR notation at all; users who for
some reason desire to set this to a single address can always use /32.
They can use a /32 but unfortunately the underlying SMF data type also
supports either an IP or a CIDR notated network address.
Just because the underlying SMF type allows for that doesn't mean you have to
accept all possibilities. Or, perhaps make a single address an implicit /32
and then the algorithm applies, but I still think that's less than ideal.
I agree they can use a /32 but it's easy enough to support a straight IP
as well; many folks have thought of a straight IP in testing these bits
before trying a CIDR notation.
Also, the range checking is necessary for the CIDR notated values. (E.g.
is network 192.168.0.1/24 in the range of 0.0.0.0/0; though perhaps I'm
missing something?)
Range checking is implicit in AND'ing two addresses against a prefix length
and comparing for equality of the results. Really, that's all you have to
do.
I agree that AND'ing would be easier, however, I haven't gotten a good
handle on KSH93 alternative bases, for example, they seem a bit off:
ad...@opensolaris:~$ typeset -i2 a=192168001001
ad...@opensolaris:~$ print $a
2#1111111111111111111111111111111110111110000110101111110111101001
ad...@opensolaris:~$ bc -l
obase=2
192168001001
10110010111110000110101111110111101001
Perhaps I'm missing something as to why this doesn't match. (Overflow?)
For now we have working code but in the future, it might reasonably be
made more simple for maintainability or just converted into Python as
desired where this can be made much more straightforward.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
