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

Grepped for -i cipher, -i crypto, 'fs'``, 'net', `'unsafe' and there were no hits except for some "unsafe" appearing in comments:

src/arrayvec.rs:    // Note: This shouldn't use A::CAPACITY, because unsafe code can't rely on
src/lib.rs://! All of this is done with no `unsafe` code within the crate. Technically the
src/lib.rs://! `Vec` type from the standard library uses `unsafe` internally, but *this
src/lib.rs://! crate* introduces no new `unsafe` code into your project.
src/array.rs:/// Just a reminder: this trait is 100% safe, which means that `unsafe` code

This crate has been added to Chromium in https://source.chromium.org/chromium/chromium/src/+/24773c33e1b7a1b5069b9399fd034375995f290b

This crate, while it implements collections, does so without std::* APIs and without unsafe. Skimming the crate everything looks reasonable and what one would expect from idiomatic safe collections in Rust.

1.6.0 (current) safe-to-run

From kornelski/crev-proofs copy of salsa.debian.org.

Packaged for Debian (stable). Changelog:

  • Team upload.
  • Package tinyvec 1.6.0 from crates.io using debcargo 2.6.0
  • Disable real_blackbox feature, it fails to build at present and nothing depends on it. It appears to only be intended for testing use anyway.

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

ub-risk-0 (implies ub-risk-1)

No unsafe code.

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

ub-risk-1 (implies ub-risk-2)
Implied by other criteria

Excellent 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-1

ub-risk-2 (implies ub-risk-3)
Implied by other criteria

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

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


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

The current version of TinyVec is 1.6.0.

0.2.0 (older version) Rating: Positive Thoroughness: Medium Understanding: High

by HeroicKatora on 2020-01-18

Very focussed forbid(unsafe) crate.

The minor flaws are introduced by trying to mimic the std interface too much and too quickly. This leads to some misbehaviour in remove and drain, several known slowness issues—algorithmic complexity as well as efficiency of operations—and poorly documented interfaces with slightly non-standard panic behaviour, and unknown decision making for adding them.

Why implement fmt::* interface when the standard library does not for Vec? How can Extend be called without risking panicking?

No safety critical flaws though and I expect most to be fixable within the interface that was published (except the abundance of trait impls that is a matter of taste).


Crates in the crates.io registry are tarball snapshots uploaded by crates' publishers. The registry is not using crates' git repositories. There is absolutely no guarantee that the repository URL declared by the crate belongs to the crate, or that the code in the repository is the code inside the published tarball. To review the actual code of the crate, it's best to use cargo crev open tinyvec. Alternatively, you can download the tarball of tinyvec v1.6.0 or view the source online.