Re: Possible Bug in bitlib under Windows?

[Tim Channon <tc@...>]

KHMan wrote:
> Andrew Gorges wrote:
>>> Was the argument 0xFFFFFFFF originally derived from a literal?
>>>
>>> If so, I'll hazard a guess that the problem happens in the Lua compiler,
>>> compile time, when the parser converts the string token 0xFFFFFFFF
>>> into a
>>> number.
>>>
>>> If your code contains the string "0xFFFFFFFF", try replacing it with
>>> "4294967295" or "2^32-1" and see what happens. If it then works, you
>>> know
>>> that the problem isn't in bitlib itself.
>>>
>>
>> I was using a numeric literal.  I tried the above constants and here
>> are the results:
>>
>> require "bit"
>>
>> print(bit.band(3, 0xFFFFFFFF))
>> -- displays 0
>>
>> print(bit.band(3, 4294967295))
>> -- displays 0
>>
>> print(bit.band(3, 2^32 -1))
>> -- displays 0
> 
> Even more fascinating...
> 
>> print(bit.cast(0x7ffffffe))
> 2147483646
>> print(bit.cast(0x7fffffff))
> 2147483647
>> print(bit.cast(0x80000000))
> -2147483648
>> print(bit.cast(0x80000011))
> -2147483648
>> print(bit.cast(-2147483647))
> -2147483647
>> print(bit.cast(-2147483648))
> -2147483648
>> print(bit.cast(-2147483649))
> -2147483648
>> print(bit.cast(-2147483700))
> -2147483648
> 
> But TOBIT() appears to work fine in MinGW, I failed to reproduce the
> problem with some rudimentary testing. LfW's bit.dll uses MSVCR80.dll,
> so I'll leave it to others to debug this thing...

Huh! :-)

Using a different compiler under win32, no gcc, no microsoft, no msvcr80

Results are almost the same.

Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> require "bit"
> print(bit.cast(0x7ffffffe))
2147483646
> print(bit.cast(0x7fffffff))
2147483647
> print(bit.cast(0x80000000))
-2147483648
> print(bit.cast(0x80000001))
-2147483648
> print(bit.cast(-2147483647))
-2147483647
> print(bit.cast(-2147483648))
-2147483648
> print(bit.cast(-2147483649))
2147483647
> print(bit.cast(-2147483700))
2147483596
>