Incorrect conversion from float64 to uint8. #733
Comments
nevkontakte
added a commit
to nevkontakte/gopherjs
that referenced
this issue
May 6, 2024
Before this change, GopherJS compiler emitted `(f >> 0)` expression to convert a float64 `f` to any non-64-bit unsigned integer type. This is incorrect, because `>>` is a signed bitshift operator in JS, so the returned value remained signed. Moreover, it did not take into account to bit size of the target type. By removing the switch cause, we make the compiler fall through to the default clause where `fc.fixNumber()` actually does the right thing, taking the target into account. Fixes gopherjs#733.
nevkontakte
added a commit
to nevkontakte/gopherjs
that referenced
this issue
May 6, 2024
Before this change, GopherJS compiler emitted `(f >> 0)` expression to convert a float64 `f` to any non-64-bit unsigned integer type. This is incorrect, because `>>` is a signed bitshift operator in JS, so the returned value remained signed. Moreover, it did not take into account to bit size of the target type. By removing the switch cause, we make the compiler fall through to the default clause where `fc.fixNumber()` actually does the right thing, taking the target into account. Fixes gopherjs#733.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Say you start with a float64 value like 300.0. If you convert it to int, it becomes 300. If you convert that int to uint8, it overflows and you get effectively 300 % 256 = 44.
In Go, when you convert float64 directly to uint8, the same process happens implicitly and the expected output is uint8(44). GopherJS doesn't implement this behavior correctly and returns an incorrect uint8 value 300.
Probably affects most of float(32,64) -> (u,)int(8,16,32,64) conversions, not just float64->uint8.
https://play.golang.org/p/AmWeBRW2G0x
https://gopherjs.github.io/playground/#/2-nWgC-jIJ
The text was updated successfully, but these errors were encountered: