Fix for issue #28012: pow overflow inconsistency #28248
Conversation
Overflows in integer pow() computations would be missed if they preceded a 0 bit of the exponent being processed. This made calls such as 2i32.pow(1024) not trigger an overflow.
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pcwalton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
Should we add a test for this? |
|
Thanks! As @ranma42 mentioned, can you be sure to add a new test for this as well? |
This would catch regressions of issue rust-lang#28012.
|
Here's that test. It just checks that the 2^1024 computation from the original issue panics, structured the same way as several other run-fail/overflowing_*.rs tests. |
Overflows in integer pow() computations would be missed if they preceded a 0 bit of the exponent being processed. This made calls such as 2i32.pow(1024) not trigger an overflow. Fixes #28012
Fix overflow checking in unsigned pow() The pow() method for unsigned integers produced 0 instead of trapping overflow for certain inputs. Calls such as 2u32.pow(1024) produced 0 when they should trap an overflow. This also adds tests for the correctly handling overflow in unsigned pow(). This was previously fixed for signed integers in #28248, but it seems unsigned integers got missed that time. For issue number #34913
Overflows in integer pow() computations would be missed if they
preceded a 0 bit of the exponent being processed. This made
calls such as 2i32.pow(1024) not trigger an overflow.
Fixes #28012