Need quick check on Intel Mac

Dar Scott dsc at swcp.com
Sat Jul 29 01:59:59 EDT 2006


On Jul 28, 2006, at 1:14 PM, Phil Davis wrote:
> On an Intel mini:
>
> Rev 2.7.2:
> put (2^32-1) bitAnd (2^32+1)
> result = 1
>
> Rev 2.6.1:
> put (2^32-1) bitAnd (2^32+1)
> result = 4294967295

Thanks, Phil, Marian, Malte and anybody else!

Rev 2.7.2 Windows:
put (2^32-1) bitAnd (2^32+1)
result = 1

Rev 2.7.2 G4 OS X:
put (2^32-1) bitAnd (2^32+1)
result = 4294967295

I guess I should let you know what that is about.  This is related to  
some trivial concerns about what happens when some function values  
are outside the specified range.

Some Revolution functions are specified only for the range of values  
that can be represented as 32-bit unsigned binary.  An example is  
binaryEncode("I",x) where "I" is a format for a 32-bit unsigned  
value.  The Revolution internal value, almost virtually string,  
probably either string or double inside, converts to that value two  
different ways for values out side the range.

Of course, it is almost always a bug if the values are outside the  
range.

If the value is above the maximum for a 32-bit unsigned integer it is  
converted two different ways.  On G4 OS X and 2.6.1 on Intel Mac, it  
sets it to the maximum allowed value.  On Windows and 2.7.2 on Intel  
Mac, it masks the value to 32 bits.  (I'm not sure what happens on  
Intel if the value is great enough that precision is lost, that is,  
greater than 2^53 or something like that.)

This also applies to the bit operators (bitNot, bitAnd, etc.).  For  
example, try this:

put bitNot bitNot (2^32+1)
== G4 OS X ==>
4294967295

So, this is trivia.

The behavior for out-of-range values that are less than 0, is  
probably to limit the value to 0 in all cases.

These are not bugs, the functions mentioned are not defined for  
values outside the range.  I have no indication that this can cause a  
crash or anything.

There is a suggestion (bz 203) that out-of-range values cause errors  
for the bit operators.  Perhaps that can also apply other places.  I  
don't have any strong feelings on that.

The bit operators should move to 48 or 64 bits as soon as they can,  
but the latter makes sense only after numbers are enhanced.  Anyway,  
the range might change.

Dar



More information about the Use-livecode mailing list