Count big bits in u64 instead of usize #143
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A 32-bit target _could_ create a giant `BigUint` over 2²⁹ bytes = 512MB, not that this would be computationally useful, but that value would have more than `usize::MAX` bits. To avoid that possibility of overflow, we can better represent bit counts in `u64`. For 64-bit targets, a `BigUint` over 2⁶¹ bytes is not realistic. This changes the public API in the return values of `bits()` and `trailing_zeros()`, as well as the `bit_size` parameter of `RandBigInt` and `RandomBits`. Trying to randomize an absurd size will naturally cause a capacity overflow, just as if you'd made a huge `Vec`.
|
I'm not certain this is a good idea -- I'll think on it for a bit before merging. Feedback welcome! |
|
Ah, let's do it. If this makes it to 0.3 and folks complain, there's always 0.4 and beyond... bors r+ |
|
Build succeeded: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A 32-bit target could create a giant
BigUintover 2²⁹ bytes = 512MB,not that this would be computationally useful, but that value would have
more than
usize::MAXbits. To avoid that possibility of overflow, wecan better represent bit counts in
u64.For 64-bit targets, a
BigUintover 2⁶¹ bytes is not realistic.This changes the public API in the return values of
bits()andtrailing_zeros(), as well as thebit_sizeparameter ofRandBigIntand
RandomBits. Trying to randomize an absurd size will naturallycause a capacity overflow, just as if you'd made a huge
Vec.