0.9.8 (current)
From mozilla/supply-chain copy of hg. By Henri Sivonen.
This review is from cargo-vet. To add your review, set up cargo-vet and submit your URL to its registry.
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
Implied by other criteria
This crate can be compiled, run, and tested on a local workstation or in controlled automation without surprising consequences. More…
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 encoding_c. Alternatively, you can download the tarball of encoding_c v0.9.8 or view the source online.
I, Henri Sivonen, wrote encoding_c for Gecko even though it is published via crates.io. There are two caveats: 1) the C API is designed to be used together with mozilla::Span and is unidiomatic for zero-length inputs otherwise. 2) It is idiomatic in C and C++ to pass uninitialized buffers as output buffers. This is generally documented to be UB in Rust, but idiomatic C and C++ usage here relies on this not actually being UB for buffers of integers (which these buffers are). See https://github.com/hsivonen/encoding_rs/issues/79#issuecomment-1211870361