These reviews are from cargo-vet. To add your review, set up cargo-vet and submit your URL to its registry.

The current version of Slab is 0.4.9.

cargo-vet does not verify reviewers' identity. You have to fully trust the source the audits are from.

safe-to-deploy (implies safe-to-run)

This crate will not introduce a serious security vulnerability to production software exposed to untrusted input. More…

safe-to-run

This crate can be compiled, run, and tested on a local workstation or in controlled automation without surprising consequences. More…

does-not-implement-crypto (implies crypto-safe)

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.

crypto-safe
Implied by other criteria

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.

unknown

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) Rating: Strong Positive Thoroughness: High Understanding: High

by LovecraftianHorror on 2023-02-16

Fundamental

  • Well maintained?
    • Maintained by the Tokio project
  • Well documented?
  • Sane dep tree?
    • Build dependency on autocfg and optional dependency on serde :)
  • Good test coverage?
    • Good when including the unstable --doctests option
    • 90.7% line coverage with cargo +nightly llvm-cov --doctests
  • Tests are passing?
  • cargo audit is happy?

Nice to have

  • cargo check is happy?
  • rustfmt is happy?
  • clippy is happy?
    • Happy on 1.66.1 at least
  • No outdated deps?

Build scripts

  • Build script(s) seem sane?
    • Only used to gate off cfgs for different rust versions

unsafe Review

  • Directly uses unsafe?
  • Passes miri if using unsafe?
    • unsafe methods are tested and this is enforced with CI

Only 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)

General Review

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) Rating: Strong Positive 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.