logo

Rust crates reviews

Cryptographically verifiable, distributed dependency reviews

crate: bytemuck

https://lib.rs/crates/bytemuck/

Add the last reviewed version to Cargo.toml / [dependencies]:

bytemuck = "1.4.1"

Filter reviews clicking on the numbers in the summary.

Full column names in tooltip hints: rating Negative, rating Neutral, rating Positive, rating Strong, thoroughness, understanding, reviews count.

Neg
Neu
Pos
Str
tho
und
rev
5
6
1
1
1
1
3
4
crate version
rating
date
reviewer
thoroughness, understanding
bytemuck 1.4.1
positive
2021-11-08
medium, medium
bytemuck 1.2.0
positive
2020-06-15
low, low
alternative:
plain
bytemuck 1.2.0
positive
2020-02-08
medium, medium

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.

bytemuck 1.1.0
strong
2019-12-11
high, high

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.

bytemuck 1.1.0
positive
2020-01-10
medium, high

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.

© bestia.dev 2021, MIT Licence, Version: 2021.1208.1729

Open source repository for this web app: https://github.com/bestia-dev/cargo_crev_web/