Hacker News Reader

Comment by j16sdiz | Hacker News Reader

This is a solution looking for a problem to solve.

This is a problem frequently complained about with language package managers: huge amounts of unvetted code which is just pulled in without being reviewed. This allows the work of vetting the code to be distributed and used by the average developer.

With Java code I get notifications on github about unsafe libraries. I also have tools to verify my dependency tree.

In new platform, this would be one of first tools, I would seek.

Disagree. One of the big selling points of Rust is the safety guarantees you get unless you use the escape hatch, which should only be used conservatively. When you add third-party code, you are trusting that the maintainers of that code have only written unsafe code where necessary and that the unsafe code is correct.

A few years ago, everybody suddenly realised that one of the big Rust HTTP libraries was full of unsafe (incorrect) code and went on a crusade to fix it. Up until that point, nobody had properly vetted it and took its lofty performance stats at face value.

Safe: Command::new("rm").args(&["-rf", "/"]).spawn()

Unsafe: unsafe { 1 + 1 }

Unsound: unsafe { &mut *(&1 as *const _ as *mut _) }

Edit: Importantly, the non-unsafe example I posted also calls a bunch of unsafe code, as is necessary to do anything nontrivial (see https://github.com/rust-lang/rust/blob/master/library/std/sr...). My point is that safe-good unsafe-bad is the wrong way to think about things. This is why you see experts on this (which I'm absolutely not) refer to unsafe code that violates the Rust Memory Model™ as unsound. (You may also find the fact the Rust Memory Model is more of a vibe than a standard surprising. How do you write sound code then? Try reasonable things and hope the compiler agrees with your definition of reasonable).

I'm not calling unsafe bad. I have no idea where you got that from.

I got it from your depiction of the actix kerfuffle. Maybe you didn't mean it, but all the original people involved who said similar things had very simplistic views of unsafe.

Sure, but cargo-crev does not seem to be about safe vs. unsafe code, it seems to be about vetted vs. unvetted code. If someone will go on to wrongly vet a big Rust library full of unsafe code, and you trust that someone's reviews, there still won't be anything that tells you of the unsafe code, if I understand correctly.

I would consider vetted vs unvetted to be a more important distinction than safe vs unsafe.

Rust has a trust model, and unsafe is an important part of that, but only a part. Unsafe means "the safety of this code relies on invariants not checked by the compiler." It does not mean "inherently unsafe." Rather, it means "trust must come from a different channel." This tool is providing such a channel.

If you want something that reports specifically on the use of unsafe code, then take a look at Cargo-Geiger.

Reply on news.ycombinator.com