-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Crypto: Improve checked add functions & add tests #8501
Conversation
|
||
match x { | ||
match bits { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this be let (hi, low) = bits;
to avoid the rightward drift?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great point. I will rebase to make this change.
Rebased to address comment by @huonw. |
The shift_add_check_overflow and shift_add_check_overflow_tuple functions are re-written to be more efficient and to make use of the CheckedAdd instrinsic instead of manually checking for integer overflow. * The invokation leading_zeros() is removed and replaced with simple integer comparison. The leading_zeros() method results in a ctpop LLVM instruction and it may not be efficient on all architectures; integer comparisons, however, are efficient on just about any architecture. * The methods lose the ability for the caller to specify a particular shift value - that functionality wasn't being used and removing it allows for the code to be simplified. * Finally, the methods are renamed to add_bytes_to_bits and add_bytes_to_bits_tuple to reflect their very specific purposes.
So, my previous implementation would fail!() if the number of bytes being added where greater than 0x1fffffffffffffff. There really isn't any good reason for that since its a perfectly valid size to add. Admittedly this is a bit pedantic - in practice its just about impossible to process that many bytes at a time. However, the whole point of this chunk of code is to handle the case where someone attempts to process more than 2^64-1 (or 2^128-1) bits, which is something that I suspect no one has ever tried to do (who tries to hash 16 billion gigabytes?). The Sha1 and Sha2 standards do, however, define a maximum message size and the only alternative to enforcing that is to ignore it. Anyway, if we're going to be strict about enforcing the maximum message size, we might as well do it right. I've rebased the commits so that any "bytes" value should work. I also updated the performance numbers, although they stay basically the same. |
I rebased all of these changes into #8272 to be easier on bors. Closing this ticket as all the changes are in that pull request now. |
More `transmute_undefined_repr` fixes fixes: rust-lang#8498 fixes: rust-lang#8501 fixes: rust-lang#8503 changelog: Allow `transumte_undefined_repr` between fat pointers and `(usize, usize)` changelog: Allow `transumte_undefined_repr` when one side is a union changelog: Fix `transumte_undefined_repr` on tuples with one non-zero-sized type.
Improve the functions that keep track of the size of the data on which a Digest is being computed and add some tests. The tests are a little redundant for the success cases - if they didn't work, the Digests that use them would fail. The failure tests are a bit more useful since its very difficult to test them through the Digests - processing 2^64+1 bits of data would take a long time!
The performance stays basically the same:
before:
after: