Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
bitcoinleveldb-comparator
A minimal, faithful Rust reimplementation of LevelDB's bytewise comparator and separator logic, extracted for use in bitcoin-rs' LevelDB-compatible storage layer.
This crate provides the comparison and key-shortening primitives that LevelDB relies on for ordering keys in its sorted string tables (SSTables) and memtables. It preserves the C++ semantics while exposing a Rust-friendly interface over byte slices.
Design intent
LevelDB orders keys using a Comparator interface. The default implementation, BytewiseComparator, orders keys lexicographically by raw bytes and provides two additional operations that are essential for index and block metadata compaction:
FindShortestSeparator: Given a start key and an upper boundlimit, mutatesstartin-place to an abbreviated key that is still within[start, limit)but lexicographically shorter, reducing index size.FindShortSuccessor: Given a key, mutates it in-place to a short lexicographic successor>= key, again minimizing key length while preserving order constraints.
This crate mirrors that behavior exactly, but for Rust, and is tailored to be binary-compatible and behaviorally aligned with Bitcoin's use of LevelDB.
Crate features
- Trait-based API that abstracts three distinct concerns:
Compare— three-way comparison of slices.FindShortestSeparator— in-place key shortening between[start, limit).FindShortSuccessor— in-place minimal lexicographic successor.
SliceComparatorunifying trait, matching LevelDB'sComparatorrole.BytewiseComparatorImpl:- Implements all traits with LevelDB-compatible semantics.
- Uses lexicographic byte ordering (
memcmp-style) via an underlyingSliceabstraction.
- Global singleton access via
bytewise_comparator()that mimics LevelDB'sstatic Comparator*pattern.
This is a low-level crate intended for engines that need precise control over on-disk key ordering and compatibility with existing LevelDB datasets.
Core traits
Compare
Compare is the fundamental three-way comparator, analogous to LevelDB's Comparator::Compare. The implementation for BytewiseComparatorImpl delegates to Slice::compare, which is expected to perform lexicographic comparison of two byte sequences.
FindShortestSeparator
Semantics (mirroring LevelDB):
- Compute the length of the common prefix between
startandlimit. - At the first differing byte
i, attempt to incrementstart[i]by 1 such that:start[i] < 0xFF, andstart[i] + 1 < limit[i].
- If possible, set
start[i] = start[i] + 1and truncatestartto lengthi + 1. - If not possible, leave
startunchanged.
This produces a key that still lies in [start_original, limit) but is often much shorter, which is highly advantageous for index blocks.
Because Rust String must be UTF-8 but LevelDB keys are arbitrary bytes, this API operates on Vec<u8>/[u8] instead of String.
FindShortSuccessor
Semantics:
- Scan from the beginning of
keyfor the first byte!= 0xFF. - Increment that byte by 1.
- Truncate
keyto this position + 1. - If all bytes are
0xFF, leavekeyunchanged.
This produces a compact successor key that remains a valid upper bound.
SliceComparator
This matches the conceptual role of LevelDB's Comparator base class and allows access to a stable, static instance.
BytewiseComparatorImpl
Implements:
DefaultCompareFindShortestSeparatorFindShortSuccessorSliceComparatorNamed(from the surroundingbitcoin-rsecosystem), returning"leveldb.BytewiseComparator".
Global singleton
This behaves like the C++ static NoDestructor<BytewiseComparatorImpl> pattern. Consumers who need raw pointers (for FFI or structural compatibility) can store and pass this pointer directly.
Note: The use of *const dyn SliceComparator is deliberate to align with LevelDB's pointer-based comparator design.
Usage
This crate is primarily intended for internal use by bitcoin-rs, but it can be consumed directly in any project that needs LevelDB-style lexicographic comparators over arbitrary byte keys.
Assume you already have the Slice type from bitcoinleveldb or the surrounding repository:
use ;
use Slice; // hypothetical path
If you need the global comparator pointer (e.g., for FFI):
use ;
Ordering semantics and correctness
All operations work at the level of raw bytes, not UTF-8 code points. This mirrors LevelDB's behavior and is essential for compatibility with existing LevelDB databases, including those used in Bitcoin implementations.
Lexicographic byte ordering is equivalent to treating keys as base-256 big-endian integers for ordering purposes. The find_shortest_separator and find_short_successor algorithms exploit this ordering to construct shorter representative keys while preserving the following invariants:
start_original <= start_modified < limit(forfind_shortest_separatorwhen modification occurs).key_original <= key_modified(forfind_short_successor).
These invariants are critical for correctly delimiting data blocks and index entries; violating them would break search correctness and could corrupt logical key ranges.
Logging
The implementation uses the log crate macros (trace!, debug!, info!) to provide fine-grained instrumentation:
trace!for entry/exit of operations and raw comparison values.debug!for mutated key states.info!for one-time initialization and naming.
To observe these logs, configure a logger such as env_logger or tracing-log in your application.
Repository and maintenance
This crate lives in the bitcoin-rs monorepo:
- Repository: https://github.com/klebs6/bitcoin-rs
Issues, bug reports, and pull requests should be filed against that repository.
License
This crate is distributed under the MIT license.