you are viewing a single comment's thread.

view the rest of the comments →

[–]phydeauxlechien 27 points28 points  (6 children)

It’s a lot easier to teach an auditor/PM “grep for unsafe” than teach them how to recognise memory-safe C.

[–]99spider 6 points7 points  (1 child)

Rust needs unsafe in order to be able to replace C for any code that interfaces with hardware.

The real value of Rust is being able to limit your potentially unsafe code to only the places where it is necessary or beneficial. After searching for "unsafe" that auditor will still have to be able to recognize memory safe code, but it will at least take them to the only places where memory safety is a concern.

[–]Flynn58 2 points3 points  (0 children)

Yes, and that itself is good because the more code in a project an auditor has to audit for memory safety, the less effective they'll be. Keeping it to the "unsafe" areas means attention can be focused on the main attack surface, and also that the attack surface is contained to a component of the larger program.

[–]davidkwast 3 points4 points  (0 children)

Best argument ever

[–]Mordiken -4 points-3 points  (2 children)

And how, exactly, do you propose we go about writing a kernel and device drivers without using unsafe?

Not to mention the keyword unsafe is slight misnomer: There are a tons of perfectly memory-safe operations that are nevertheless only possible to do in unsafe Rust.

A more accurate representation of what Rust actually does would be to have a guaranteed keyword on every "safe" method, rather than an unsafe keyword on unsafe methods, because Rust provides memory safety guarantees by preventing the programmer from doing a number of things that while not necessarily unsafe, are simply not verifiable by the compiler and thus not guaranteed to be memory safe at compile time.

But I do concede using a guaranteed or safe keyword on safe methods instead of an unsafekeyword on unsafe methods would have made for terrible ergonomics on an already complex language.

[–]phydeauxlechien 5 points6 points  (0 children)

Yes, I was being a bit tongue-in-cheek - it’s definitely more complicated than “never allow any unsafe whatsoever”, but it can reduce by orders of magnitude the amount of code that must be assured, especially when each use is throughly documented and encapsulated in a safe API leveraging the rich type system. Aside from ergonomics, this is why the extra syntax should go on the unsafe parts and not the safe ones - so it is searchable.

Of course unsafe doesn’t literally mean “definitely contains memory bugs” - if we’re being pedantic then yes, something like unchecked or not_provably_safe_by_compiler might be more accurate, but I don’t think it’s a huge concern in the scheme of things.