Closed GoogleCodeExporter closed 9 years ago
The optimization was also incorrect in the script engine (now fixed)
For the purpose of the forcing an unsigned value, I'm considering adding an
Unsigned() built-in function, which would also allow considering an Int64 value
in the script engine to be an unsigned.
Is there a source code version of the hash I could use to test if the
Unsigned() would be practical?
Original comment by zar...@gmail.com
on 4 Feb 2014 at 10:39
Unsigned() could make sense, you are right.
".. shr 0" is just a Javascript tweak.
About the hash, you can take a look at
http://blog.synopse.info/post/2012/04/19/Smart%3A-mORMot,-from-Delphi-to-JavaScr
ipt
The CRC32 computation is enough to have a reference use of ".. shr 0".
SHA-256 could be also useful.
Thanks a lot for the quick fix!
Original comment by arn...@gmail.com
on 4 Feb 2014 at 12:51
Hmmm, the CRC32 code fails script-side where integers are 64 bits, as it
assumes a 32bit integer for the "not" and the subsequent bit shift.
That said other CRC32 implementations I found did not have the initial & final
"not" your code has, and so did not exhibit bitness issues.
I'm wondering about the above about what Unsigned() should mean, and if
Unsigned32/Unsigned64 distinction is warranted. Script-side both can be
handled, JS-side, only Unsigned32 is possible. So I guess I'll stick with
Unsigned() getting the highest bit count unsigned.
Original comment by zar...@gmail.com
on 4 Feb 2014 at 1:27
Hmm, scratch the above, it doesn't float. Unsigned() to the highest precision
would require returning a float (otherwise it's just a nop), so only
Unsigned32() makes sense.
Script side it would be equivalent to an "and $FFFFFFFF" and JS-side to a ">>>
0".
Original comment by zar...@gmail.com
on 4 Feb 2014 at 1:39
Original comment by zar...@gmail.com
on 4 Feb 2014 at 2:09
Original issue reported on code.google.com by
arn...@gmail.com
on 3 Feb 2014 at 3:55