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 Memchr is 2.7.2.

2.7.1 — diff review from 2.6.4 only (older version) safe-to-deploy

From zcash/rust-ecosystem copy of zcash/zcash. By str4d.

Change to an unsafe fn is to rework the short-tail handling of a fixed-length comparison between u8 pointers. The new tail code matches the existing head code (but adapted to u16 and u8 reads, instead of u32).

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.

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

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 Memchr is 2.7.2.

2.2.1 (older version) Rating: Strong Positive Thoroughness: High Understanding: High

by BurntSushi on 2019-08-22

I wrote this crate, so this review is a reflection as a result of writing the code and then reviewing it again for this review.

The entire purpose of the memchr crate is to do this:

haystack.iter().position(|&b| b == needle)

... but really fast. As a result, this crate uses SIMD via CPU specific vendor intrinsics. Consequently, there is a lot of unsafe code in this crate. There is really no way to avoid this, other than perhaps using a higher level platform independent SIMD API. But no such thing of sufficient quality exists for stable Rust at the time of writing.

The testing strategy is the most important bit here. In particular, every public API item is tested using a permutation of tests that exercise all possible alignments found in a haystack. (Because the implementations used aligned loads/stores, which are only correct if the address arithmetic is correct.) Additionally, there are quickcheck tests that act as a sort of fuzzer guaranteeing that the implementation is correct for a range of inputs.

I gave the highest rating possible because of the extensive use this crate has seen, in addition to its level of testing. In particular, memchr underlies a significant chunk of all text search in the Rust ecosystem.

2.1.2 (older version) Rating: Neutral Thoroughness: Low Understanding: Medium

by HeroicKatora on 2019-08-30

Not sure about the strict correctness of memrchr under stacked borrows but the forward functions definitely seem fine. That said, miscompilation seems unlikely since stacked borrows is more aggressive than llvm's noalias and raw pointers do not receive that tag anyways.


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 memchr. Alternatively, you can download the tarball of memchr v2.7.2 or view the source online.