Refactor `[u8]` -> `[u8; LEN]` where appropriate
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 45/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- rust
- Domain
- cryptography
Research direction
Start at the core::traits::Hash definition shown in the issue, then inspect its implementations and the discussion in #49. Search the library for Vec and &[u8] values representing fixed-length data; done means the appropriate APIs use fixed-size arrays without losing implementation agnosticism, and the library still compiles.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- Rust
- Stars
- 25
- Forks
- 18
- Avg merge
- 14d 10h
- Merged PRs (30d)
- 5
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from bcgit/bc-rust
-
Improve docs in FactoriesPossibly taken @pollychen-lab claimed this 5 days ago. Opendocumentation good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
bcgit/bc-rust#161 · 1 reaction ·
Maintainers usually reply within 2 days
-
good first issue refactor
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
Maintainers usually reply within 2 days
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
bcgit/bc-rust#163 · 2 comments ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Maintainers usually reply within 2 days
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
pyca/verified-garbage#1023 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 74/100
-
review-drift
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
oxidecomputer/hansei#14 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
rubys/roundhouse#444 ·
Maintainers usually reply within 1 day
-
Published hardy-bpa-server image is built without the file-cla featurePossibly taken @EmbryoSpace claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
ricktaylor/hardy#755 ·
Maintainers usually reply within 1 day