Support allocation free usage of bcrypt#95
Merged
Keats merged 4 commits intoKeats:masterfrom Feb 28, 2026
Merged
Conversation
This doesn't need to be dynamically allocated. The logic is relatively simple - ensure it starts as a null terminated string, but truncate at 72 bytes. We can simply zero fill a stack buffer (thereby ensuring the last byte is a null byte) and then copy into it up until that last byte if we are not truncating, and including the last byte if we are, preserving the previous behavior with no dynamic allocation.
Keats
requested changes
Feb 25, 2026
HashParts previously stored base64-encoded salt and hash as heap-allocated Strings. They are now stored as raw bytes ([u8; 16] and [u8; 23]). Encoding and decoding of base64 happens with slices now rather than internally allocating as well. This change aims to provide a way for callers to avoid dynamic allocation entirely, if desired, while maintaining existing public method signatures for backwards compatibility. It adds similar methods to public methods that already existed that allow callers to do the same thing (retreive salt, get bcrypt format string, etc.) in allocation free ways.
Adds allocation free variants of all public hashing functions, to provide a mechanism for users to use bcrypt fully alloc free if they want.
PrismaPhonic
force-pushed
the
peter/stack-based
branch
from
ca6cfd0 to
7b2ca8d
Compare
This removes a vec usages (just used to split the incoming hash string into it's parts) with a solution that avoids allocating.
Contributor
Author
|
I just realized I forgot one spot: |
Owner
|
Thanks! |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
In embedded,
no_std, or latency-sensitive environments, every heap allocation matters. The existing API forces allocations in places that don't inherently need them - most notably duringverify, where data was being encoded and decoded purely to pass through heap-allocated fields that existed only as an internal implementation detail.This PR eliminates those unnecessary allocations while leaving the existing public API unchanged. The internal representation was always an implementation detail, and callers are not affected.
For callers who want to go further and avoid heap allocation entirely on the output side too this adds new
_bytesvariants of every public hash function.HashPartsalso gains awrite_for_versionmethod that accepts anyfmt::Writesink, allowing callers to write the hash string directly into stack-allocated string types (e.g. fromarrayvecorheapless) without any intermediate heap allocation.