Repository navigation
Refactor [u8] -> [u8; LEN] where appropriate #102
Description
Activity
It might be that this is not really implementable until the rust compiler
generic_const_exprsfeature, which is currently only available in nightly, lands in stable.I recall attempting this some time ago, and there were two difficulties:
- The OUTPUT_LEN argument propagates to any other struct that impls Hash (which may be repeating a size that is already an associated constant)
- There were some cases that were not possible to handle (possibly in bouncycastle-factory?) because generic_const_exprs was required to satisfy the const generic arg for Hash.
Another approach would be to make impacted functions generic instead, rather than the trait itself, e.g.:
fn hash_out<const N: usize>(self, data: &[u8], output: &mut [u8; N]) -> usize; fn hash_array<const N: usize>(self, data: &[u8]) -> [u8; N] where Self: Sized, { let mut output = [0u8; N]; let _ = self.hash_out(data, &mut output); output }
since that resolves runtime ambiguity about the length of those arrays. Since this is part of the mathematical definition of a hash function, this should still be implementation-agnostic (ie any hash function should be able to implement this).
Except for XOF ones, but perhaps you use a different interface for them?
bc-rust follows the general Rust paradigm of moving as many runtime error conditions as possible to instead be compile-time error conditions.
A prime candidate is core::traits:Hash:
Since, by definition, a hash function must produce a fixed-size output, this should really be:
since that resolves runtime ambiguity about the length of those arrays. Since this is part of the mathematical definition of a hash function, this should still be implementation-agnostic (ie any hash function should be able to implement this).
The task is to make the refactor above, and scan through the rest of the library for any other places where a value with a fixed length is currently being handled as an indefinite-length type (Vec or &[u8]).
This task is related to #49 , but not necessarily a subtask, since if we decide to keep the requirement on a global allocator, then the current
Vec<u8>implementation does not technically need to change.