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:
pub trait Hash: Algorithm + Default {
...
fn hash(self, data: &[u8]) -> Vec<u8>;
fn hash_out(self, data: &[u8], output: &mut [u8]) -> usize;
...
}
Since, by definition, a hash function must produce a fixed-size output, this should really be:
pub trait Hash<const OUTPUT_LEN: usize>: Algorithm + Default {
...
fn hash(self, data: &[u8]) -> [u8, OUTPUT_LEN];
fn hash_out(self, data: &[u8], output: &mut [u8; OUTPUT_LEN]) -> usize;
...
}
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.
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.