I'm not strictly opposed to adding a dependency on zerocopy

For the avoidance of doubt, the Rust standard library depends on zerocopy, so it's already a transitive dependency. In an of itself, not a justification for taking the dependency, but possible useful to know.

As a code level concern: the bindings files are autogenerated so any changes made manually will be overwritten the next time I run regenerate.sh. You will need to modify regenerate.sh to make this change automatically.

I incorrectly concluded that the different authors over time appearing in a git blame meant that these files had been hand-edited. I'm going to change the bindgen scripts instead.

As such, I'd like to know where else you think it would be useful.

Good point. I have found several places. Consider the Sampler::page method, which returns a raw pointer, and all the subsequent reads of this struct's fields. While the subsequent atomic loads will still need to drop to unsafe, a couple of the computations with respect to the fields of perf_event_mmap_page's fields can be hoisted to safe code. It would be very useful to return a reference instead.

Lastly, even though we can trivially reason about the safety of transmutes from repr(C) structs, zerocopy offers a means to automate this on all architectures, for every possible change to the C API, forever. I want to emphasize that it's not just hiding the unsafe code, it's actually performing architecture-specific reasoning that would be quite burdensome to do manually. Most importantly, zerocopy will refuse to allow the code to compile if it finds something that would make the transmutes unsound, like an abstruse platform-specific alignment requirement, for example. YMMV, but I've found that zerocopy has made me point the proverbial gun away from my own foot many times.