-
Notifications
You must be signed in to change notification settings - Fork 377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Correctly write Long.toBinaryString as an unsigned value #9769
Conversation
A patch made to GWT last year introduced a bug in turning Longs to strings - while the same patch was made to J2CL, it did not have an issue with signs, so these tests should pass as-is. With that said, there was no test coverage for values that are positive as longs, but negative when treated as an int, with all high bits set. See gwtproject/gwt#9769 Closes #155 PiperOrigin-RevId: 464563372
I made a quick performance test of the range check vs high bit check, and found that while chrome saw small performance improvements (or at worst saw the same performance most of the time), firefox saw significantly worse performance by making this change, for longs that don't fit in int32. The losses by firefox seemed (from a small sample size) to be worse than the gains seen in chrome, so at least for now I'm voting for keeping the status quo. In this sample GWT2 app, v1 is the current check that is done, and v2 is the attempted improvement. My theory was that it was cheaper to compare against constants rather than shift, even for large numbers, but that seems to not universally be true.
I'll roll back that attempted improvement, and mark this pull request as ready for review. |
A previous fix to negative longs incorrectly allowed some positive longs that would be represented as negative ints to be printed as negative binary values, instead of as unsigned values. This patch fixes that case and adds tests to confirm that these edge cases are well represented. This bug was introduced by 7616ceb. The binary, hex, and octal tests all fail before this change, the toString test was just for completeness, but wasn't actually broken. Fixes gwtproject#9764
90623ea
to
916d48d
Compare
A previous fix to negative longs incorrectly allowed some positive longs
that would be represented as negative ints to be printed as negative
binary values, instead of as unsigned values. This patch fixes that case
and adds tests to confirm that these edge cases are well represented.
This bug was introduced by 7616ceb.
The binary, hex, and octal tests all fail before this change, the
toString test was just for completeness, but wasn't actually broken.
Additionally, getHighBits could be expensive, and a range check against
two constants (that easily fit in a "small long") should be cheaper at
runtime. This is not required for the fix, and I will validate this
performance assumption.
Fixes #9764