0.4.9 (current)
From kornelski/crev-proofs copy of salsa.debian.org.
These reviews are from cargo-vet. To add your review, set up cargo-vet
and submit your URL to its registry.
0.4.9 (current)
From kornelski/crev-proofs copy of salsa.debian.org.
The current version of Slab is 0.4.9.
0.4.8 — diff review from 0.4.7 only (older version)
From mozilla/supply-chain copy of hg. Audited without comment by Mike Hommey.
0.4.8 (older version)
From kornelski/crev-proofs copy of git.savannah.gnu.org.
Packaged for Guix (crates-io)
0.4.7 (older version)
From google/supply-chain copy of chromium. Audited without comment by George Burgess IV.
0.4.7 (older version)
From google/supply-chain copy of chromium. Audited without comment by Android Legacy.
0.4.6 (older version)
From bytecodealliance/wasmtime. By Pat Hickey.
provides a datastructure implemented using std's Vec. all uses of unsafe are just delegating to the underlying unsafe Vec methods.
cargo-vet does not verify reviewers' identity. You have to fully trust the source the audits are from.
This crate can be compiled, run, and tested on a local workstation or in controlled automation without surprising consequences. More…
Inspection reveals that the crate in question does not attempt to implement any cryptographic algorithms on its own.
Note that certification of this does not require an expert on all forms of cryptography: it's expected for crates we import to be "good enough" citizens, so they'll at least be forthcoming if they try to implement something cryptographic. When in doubt, please ask an expert.
All crypto algorithms in this crate have been reviewed by a relevant expert.
Note: If a crate does not implement crypto, use does-not-implement-crypto
,
which implies crypto-safe
, but does not require expert review in order to
audit for.
This crate will not introduce a serious security vulnerability to production software exposed to untrusted input. More…
May have been packaged automatically without a review
These reviews are from Crev, a distributed system for code reviews. To add your review, set up cargo-crev
.
The current version of Slab is 0.4.9.
0.4.7 (older version) Thoroughness: High Understanding: High
by LovecraftianHorror on 2023-02-16
autocfg
and optional dependency on serde
:)--doctests
optioncargo +nightly llvm-cov --doctests
cargo audit
is happy?cargo check
is happy?rustfmt
is happy?clippy
is happy?
cfg
s for different rust versionsunsafe
Reviewunsafe
?miri
if using unsafe
?
unsafe
methods are tested and this is enforced with CIOnly uses unsafe
to expose three unsafe methods on Slab
Slab::get_unchecked()
is just an analog to [T]::get_unchecked()
and
internally calls [T]::get_unchecked()
on the underlying vector. The caller
MUST call this method on an occupied entry within the bounds of the underlying
vector. Calling it outside of bounds is undefined behavior while calling it on
a Vacant
entry will panic (hits unreachable!()
) although this may be
relaxed to unreachable_unchecked()
in the future a la
https://github.com/tokio-rs/slab/issues/40
Slab::get_unchecked_mut()
is the same situation as Slab::get_unchecked()
.
Also an analog of the slice method and also the same UB and panic behavior
Slab::get2_unchecked_mut()
provides a way to get a mutable reference to two
elements in the Slab
without bounds checking. This has the same invariants
as the other two (UB if out of range and panics on Vacant
entries) along
with the additional invariant that the two elements have to be different to
prevent multiple mutable references to the same element. The last invariant is
enforced with a debug assert. Because there is no analog for slices this
manually implements the addressing in a similar way to
[T]::get_unchecked_mut()
although it would be nice to have a debug assert
that the indices are in range (the standard library uses
assert_unsafe_precondition!()
to do this on [T]::get_unchecked()
and
[T]::get_unchecked_mut()
which gets picked up by cargo-careful
)
lib.rs
Essentially a Vec
where removed elements get replaced by a vacant entry
marker instead of shifting down all later values to compact. All vacant
entries store an index pointing to some other vacant entry with the last
vacant entry pointing to the end of the Slab
. The Slab
itself then stores
a next
value pointing to the top of the stack so that it can keep track of
where all vacant entries are to efficiently push on new values. These
underlying entries are never publicly exposed to prevent users from mangling
this stack
Overall everything looks good. The Slab
seems to correctly maintain its
invariants at all times and there is a nice sprinkling of asserts and debug
asserts to handle sanity checking
serde.rs
Contains the optional serde::{Serialize, Deserialize}
impls for Slab
. It
just (de)serializes as a map with the deserialization performing the same
operations as the FromIterator
implementation
0.4.1 (older version) Thoroughness: High Understanding: High
by HeroicKatora on 2019-08-31
No internal use of unsafe. Only an get_unchecked unsafe api without bounds that translates directly to Vec and does not exploit the possible unsafety in its implementation to the fullest extent (unreachable instead of unreachable_unchecked).
Lib.rs has been able to verify that all files in the crate's tarball are in the crate's repository with a git tag matching the version. Please note that this check is still in beta, and absence of this confirmation does not mean that the files don't match.
Crates in the crates.io registry are tarball snapshots uploaded by crates' publishers. The registry is not using crates' git repositories, so there is a possibility that published crates have a misleading repository URL, or contain different code from the code in the repository.
To review the actual code of the crate, it's best to use cargo crev open slab
. Alternatively, you can download the tarball of slab v0.4.9 or view the source online.
Only in debcargo (unstable). Changelog: