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

The current version of UCS-2 is 0.3.3.

0.3.2 (older version) Rating: Positive Thoroughness: High Understanding: High

by HeroicKatora on 2021-12-16

CI coverage is good, running both rustfmt and clippy on every push, regardless of branch. It does not seem to run specifically on pull requests, which, I believe, leads to Github not checking the merge commit specifically but instead just individual commits on the remote branch. Not too consequential in any case, just slightly unorthodox.

Since 0.2.0 (the previous review) decoding has been added which seems to have resulted in an additional internal dependency (bit_field) that has not yet reached 1.0. However, it remained stable for the past year. It's not immediately clear why a simple shift-and-mask would not be clean enough here, the traits provided by the dependency seem much more relevant if they help enable an interface or generic implementation—which is both not required here.

The decode interface looks sound and decently usable. There is an interesting difference in that its _with variant returns a count on success whereas the encoding methods do not. Additionally, it's unclear how to efficiently and properly react to an OverflowError because neither the number of successfully consumed input nor the actually required output would be available to the caller.

The encode interface is unchanged since 0.2.0. Thus I'm preserving the previous review.

Contains unsafe code as a mechanism to eliminate bounds checks by asserting properties with unreachable_unchecked. However, this appears to make proper (and only proper) use of the unsafe assertion that strings are valid UTF-8 given by the standard library.

The unsafe code is documented and the reasoning behind it is explained. The only minor flaw is that it does not properly explain that the validity invariant used is being tested for. Since it does reference both utf-8 and the byte length in its argument this should be straightforward to the reader though.

A slightly cleaner way of testing the conditions might have been matching the first byte with integer ranges, which would have eliminated the last bounds check without an additional unreachable assertion.

No strong rating due to superficially unimportant dependency, and concerns about the maturity of the interface (see above).

It remains unclear if an iterator based design instead of callbacks was considered, potentially placing control flow in the hands of the caller. This may be important for some cases where buffers need to be flushed while efficiently preserving the decoding state.

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

by HeroicKatora on 2020-01-11

Show review…

Contains unsafe code as a mechanism to eliminate bounds checks by asserting properties with unreachable_unchecked. However, this appears to make proper (and only proper) use of the unsafe assertion that strings are valid UTF-8 given by the standard library.

The unsafe code is documented and the reasoning behind it is explained. The only minor flaw is that it does not properly explain that the validity invariant used is being tested for. Since it does reference both utf-8 and the byte length in its argument this should be straightforward to the reader though.

A slightly cleaner way of testing the conditions might have been matching the first byte with integer ranges, which would have eliminated the last bounds check without an additional unreachable assertion.

No strong rating since the crate is incomplete and the trust of maintainers is not clearly established.

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

by izik1 on 2019-11-10

Verified by reading the entire crate and ensuring that it matched the utf-8 -> ucs2 transformation format.

  • positives
    • definitely conforms to transformations, definitely doesn't panic. Definitely safe.
  • negatives
    • has Error::BufferUnderflow and Error::InvalidData which are both unreachable due to the guarantees of &str.

This review is from cargo-vet. To add your review, set up cargo-vet and submit your URL to its registry.

The current version of UCS-2 is 0.3.3.

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.


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 ucs2. Alternatively, you can download the tarball of ucs2 v0.3.3 or view the source online.