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

The current version of bytemuck is 1.12.1.

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

Approved without comment by inflation on 2021-11-08

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

Approved without comment by kornelski on 2020-06-15

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

by HeroicKatora on 2020-02-08

The crate gained quite a bit of interface since last time. I'm not quite sure how I feel about this at the moment but understanding definitely suffered from it.

Of most concern is definitely TransparentWrapper which relies on the internal implementation detail that the layout of a pointer type itself does not change for transparent wrappers. This premise seems a very unlikely to be invalidated from changes but nevertheless departs with only relying on stabilized and fully RFCed properties.

Other than that, no critical changes and a continued trend of being cautious. Notably the implementation of Contiguous guards against bad implementations despite being unsafe to implement, the offset_of macro is completely safe(!)—a welcome change for such macros—and there are MIRI tests in CI.

The test suite could be a lot bigger but some tests are obviously foiled by MIRI rejecting some sound and UB-free code that relies on alignment checks, to avoid those incidentally succeeding in unsound code.

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

by HeroicKatora on 2020-01-10

Show review…

The implementation is rather conservative on many fronts and requires very strong, sometimes even unnecessary, preconditions for all operations. But this makes reasoning easier since you work with a consistent set of assumptions. This is in contrast to zerocopy which has at three differing sets.

The biggest leap of unsafety is the assumption that slices strides and arrays agree with the size of their elements. This is not quite likely to change, ever, but it should be noted nevertheless. The exact wording of Pod also allows us to smuggle a type through its requirements. It takes some care to try and only allow types that might violate the assumption by requiring a defined repr but in its wording forgets that repr(packed) can be applied to repr(rust). Thus, the following type conforms to the wording but not the spirit behind it.

\#[repr(packed)] struct BadSize(u16, u8)

The easiest fix would be to explicitly list the requirement that the size is divisible by the alignment. This defines the stride to agree with the size.

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

by Lokathor on 2019-12-11

This is my crate. It's been in careful development for several months now, and it keeps everything as minimal and simple as possible to avoid any possible unsoundness.

Crates in the 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 bytemuck. Alternatively, you can download the tarball of bytemuck v1.12.1.