> it was effectively "are there meaningful safety features provided to the unsafe zlib-rs code in question in that aren't already available in C toolchains/ecosystems?"

Ah, so that was like, not in your comment, but in a parent.

> And there really aren't.

I mean, not all of the code is unsafe. From a cursory glance, there's surely way more here than I see in most Rust packages, but that doesn't mean that you get no advantages. I picked a random file, and chose some random code out of it, and see this:

    pub fn copy<'a>(
        dest: &mut MaybeUninit<DeflateStream<'a>>,
        source: &mut DeflateStream<'a>,
    ) -> ReturnCode {
        // SAFETY: source and dest are both mutable references, so guaranteed not to overlap.
        // dest being a reference to maybe uninitialized memory makes a copy of 1 DeflateStream valid.
        unsafe {
            core::ptr::copy_nonoverlapping(source, dest.as_mut_ptr(), 1);
        }

The semantics of safe code, `&mut T`, provide the justification for why the unsafe code is okay. Heck, this code wouldn't even be legal in C, thanks to strict aliasing. (Well, I guess you could argue that in C code they'd be of the same type, since you don't have "might be uninitialized" in C's typesystem, but again, this is an invariant encoded in the type system that C can't do, so it's not possible to express in C for that reason either.)