Use typeset -li or integer to get a 64bit integer in ksh93. typeset -i is 32bit, except for Solaris 10 ksh which was supposed to be 32bit but was hacked to be 64bit, breaking backwards compatibility with ksh88 on other platforms.
typeset -si is 16bit typeset -i is 32bit typeset -li is 64bit future versions will support typeset -lli for 128bit ksh93 -c 'typeset -li2 bi ; (( bi=10#192168001001 )) ; print $bi' 2#10110010111110000110101111110111101001 Olga On Fri, Jul 30, 2010 at 1:03 PM, <[email protected]> wrote: > 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 > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ [email protected] \-`\-'----. `'-..-| / http://twitter.com/fleyta \ |-..-'` /\/\ Solaris/BSD//C/C++ programmer /\/\ `--` `--` _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss

