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

Reply via email to