Lib.rs

› ScopeGuard › Reviews

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 ScopeGuard is 1.2.0.

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

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-run

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

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

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

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 ScopeGuard is 1.2.0.

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

by HeroicKatora on 2020-04-29

Small, stable, and highly useful.

Most of the code is straightforward but to increase usability there are three unsafe blocks. It seems feasible to write a completely safe version of the API without hurting the main use case too much. The benefit, however, would be slim except for those focussed on purging even well-reviewed local unsafe. Let's explain how we agree with all reasoning, and documentation.

src/lib.rs:351:ScopeGuard::into_inner: Here it performs a manual move from a to-be-forgotten value that can't be destructured due to the rules around Drop types. It's slightly awkward to use mem::forget after the copy instead of wrapping the value in a ManuallyDrop at the start but the comment correctly explains why the order is equivalent and still sound. It also seems odd that this pseudo-destructuring does not return the function instance but only the value and thus always drops the functor which potentially also drops any contained captured value and thus might panic. That seems more ergonomic in the common case or when a pure function is used, so it isn't critical.

src/lib.rs:422:impl Sync: This is likely the most involved here but the comment explains it well enough. It might have been/be beneficial to create a very small newtype wrapper that enforces that no such access by reference can take place in future versions of the crate also. This would also reduce the mental load, as this impl with all its type bounds would not be explicitly required. It would nevertheless not reduce the amount of necessary soundness reasoning so this is just polish.

src/lib.rs:455:Drop::drop for ScopeGuard: Same as into_inner but since this is within the Drop impl there is no need (and possibility) to forget self so this is self-explanatory. This could share a common core with the into_inner method, a private inherent method that ptr::read's the stored values. Avoiding duplication here would be more important if different ways of destructuring existed.

1.0.0 (older version) Rating: Positive Thoroughness: Low Understanding: Low

by dpc on 2019-10-04

No malicious code. The unsafe parts seems sane, but they could use a a review by someone more confident with unsafe.

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

by git.sr.ht/~icefox on 2019-08-21

Looks okay but I'd prefer to just avoid needing it.

0.3.3 (older version) Rating: Positive Thoroughness: Low Understanding: Medium

Approved without comment by dpc on 2020-01-02

Lib.rs has been able to verify that all files in the crate's tarball, except Cargo.lock, 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 scopeguard. Alternatively, you can download the tarball of scopeguard v1.2.0 or view the source online.