>Hi Dragan,
>
>< snip >
>>You only have to take care of BitLShift(), because BITAND( ),BITCLEAR( ), BITOR( ) , BITSET( ), BITTEST( ) and BITXOR( ) will not produce more bits in the result than there were in the operands.
>
>It would be true if foxpro kept results as 16 bit integers.

They'll be 32-bit, of course, but if operands had zeros above 15th bit, so would the results, except as stated below, and, well, more correct way to put it is that the results would still be in 16 bit value range.

I figure whoever wrote the original code was playing a risky game, relying on shortint being always signed 16-bit. The size of integers may change across versions. I've seem that happen in some languages. At some point int was 16 and shortint 8 bits, then it was renamed to int of 32, shortint of 16 and smallint of 8 bits. I've also seen 64-bit integers, and 48-bit as well.

>Keep in mind that BITNOT( ) will produce a 32-bit complement of your integer, i.e. if in 16 bit arithmetic bitnot(0) will be 0x0000ffff, in 32-bit it will be 0xffffffff. Also, doing Bitor() and BitXor() where one operand may be negative or above 32767, will yield numbers outside of the 16-bit range. The safe thing to do (if you want to keep it 16-bit) is to strip the upper 16 bits:
>>
>>function bitor16(n1,n2)
>>return bitand(bitor(n1,n2), 0x0000ffff)
>>
>>function bitxor16(n1,n2)
>>return bitand(bitxor(n1,n2), 0x0000ffff)
>
>Here's the test

>lnNumber = BitLshift16( 1, 15)     && -32768 or 0xFFFF8000
>* As you can see it has already more bits that we want
>? Bitand(Bitxor( lnNumber, 0), 0xffff)   && returns 32768 instead of -32768
>

Really tricky - and I'd still blame it on the original programmer.