6 ms·

> basically written in C Unsafe Rust still has to conform to many of Rust’s rules. It is meaningfully different than C.

• est31 2y ago
  It has also way less tooling available than C to analyze its safety.
  • nindalf 2y ago
    The number of tools matters less than the quality of the tools. Rust’s inherent guarantees + miri + software verification tools mean that in practice Rust code, even with unsafe, ends up being higher quality.
  • wyager 2y ago
    Miri is better than any C tool I'm aware of for runtime UB detection.
    • est31 2y ago
      Miri is the closest to a UB specification for Rust that there is, coming in the form of a tool so you can run it. It's really cool but Valgrind, which is a C tool that also supports Rust, also supports Rust code that calls to C and that does I/O, both pretty common things for programs to do.
  • vlovich123 2y ago
    The things I’ve seen broadly adopted in the industry (i.e. sanitizers) are equally available in Rust. & Rust’s testing infrastructure is standardized so tests are actually common to see in every library.
• ajross 2y ago
  Are there examples you're thinking about? The only good ones I can think of are bits about undefined behavior semantics, which frankly are very well covered in modern C code via tools like ubsan, etc...
  • sedatk 2y ago
    This comment summarizes the difference of unsafe Rust quite well. Basically, mostly safe Rust, but with few exceptions, fewer than one would imagine: https://news.ycombinator.com/item?id=43382176 https://news.ycombinator.com/item?id=43382176
  • steveklabnik 2y ago
    They're just fundamentally different languages. There's semantics that exist in all four of these quadrants: * defined in C, undefined in Rust * undefined in C, undefined in Rust * defined in Rust, undefined in C * defined in Rust, defined in C
    • ajross 2y ago
      That doesn't seem responsive. The question wasn't whether Rust and C are literally the same language ("duh", as it were), 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?" And there really aren't. The abbreviated/limited safety environment being exploited by this non-idiomatic Rust code seems to me to be basically isomorphic to the way you'd solve the problem in C.
      • steveklabnik 2y ago
        > 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.)