Lib.rs

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

1.1.8 — diff review from 1.1.7 only (current) safe-to-deploy

From zcash/rust-ecosystem copy of zcash/zcash. By Daira Emma Hopwood.

Adds unsafe code that makes an assumption that ptr::null_mut::<Entry<T>>() is a valid representation of an AtomicPtr<Entry<T>>, but this is likely a correct assumption.

The current version of ThreadLocal is 1.1.8.

1.1.7 — diff review from 1.0.1 only (older version) safe-to-deploy, ub-risk-2

From google/supply-chain copy of fuchsia. By David Koloski.

Reviewed on https://fxrev.dev/906819

1.1.7 — diff review from 1.1.4 only (older version) safe-to-deploy

From zcash/rust-ecosystem copy of zcash/zcash. By Jack Grigg.

New unsafe usage:

• An extra deallocate_bucket, to replace a Mutex::lock with a compare_exchange.
• Setting and getting a #[thread_local] static mut Option<Thread> on nightly.

1.1.7 (older version) unknown

From kornelski/crev-proofs copy of git.savannah.gnu.org.

Packaged for Guix (crates-io)

1.1.4 (older version) safe-to-run, does-not-implement-crypto

From google/supply-chain copy of chromium. Audited without comment by George Burgess IV.

1.1.4 (older version) safe-to-deploy

From bytecodealliance/wasmtime. By Pat Hickey.

uses unsafe to implement thread local storage of objects

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

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.

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

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

ub-risk-2 (implies ub-risk-3)

Negligible unsoundness or average soundness.

Full description of the audit criteria can be found at https://github.com/google/rust-crate-audits/blob/main/auditing_standards.md#ub-risk-2

ub-risk-3 (implies ub-risk-4)

Implied by other criteria

Mild unsoundness or suboptimal soundness.

Full description of the audit criteria can be found at https://github.com/google/rust-crate-audits/blob/main/auditing_standards.md#ub-risk-3

ub-risk-4

Implied by other criteria

Extreme unsoundness.

Full description of the audit criteria can be found at https://github.com/google/rust-crate-audits/blob/main/auditing_standards.md#ub-risk-4

unknown

May have been packaged automatically without a review

---

This review is from Crev, a distributed system for code reviews. To add your review, set up cargo-crev.

The current version of ThreadLocal is 1.1.8.

0.3.6 (older version) Rating: Positive Thoroughness: Medium Understanding: Medium

by BurntSushi on 2019-08-22

This crate was written by Amanieu d'Antras in response to my efforts to make thread safe caching in the regex crate faster. The way to think about it is "dynamic" thread local storage.

The crate does use a fair amount of unsafe, and the reason for this is to minimize latency as much as is possible. Each use of unsafe isn't particularly tricky---it's mostly managing atomic access to a hash table. With that said, it would be nice if each use of unsafe had a comment explaining/justifying it. There are some comments scattered about making reasonable arguments, but more would be good.

This crate did have an issue a while back where if a program used the same regex (for example) many times from many short lived threads, then the cached data could grow without bound. Amanieu patched that issue a while back by reusing thread ids. A thread id is tracked using normal TLS, which is dropped when the thread is destroyed.

I gave this crate a rating of positive because I cannot identify any issues after reviewing the code, although, I am not completely certain that there are no issues because of the use of unsafe code.