I recently wrote a tool that helps with auditing unsafe blocks:
https://github.com/huonw/unsafe_ls
It lists all the unsafe blocks in a crate and prints the lines with the
actual unsafe actions on them, with a crude filter to omit FFI (and/or
only see FFI). This doesn't do anything intelligent at all, just makes
it easier for humans to find and read any unsafe code; and it's still up
to the programmer to work out what safe code needs to be checked too.
(Works well with emacs' compilation-mode, in my experience.)
Huon
On 04/03/14 13:58, Patrick Walton wrote:
It's plain hyperbolic to call Rust's unsafe blocks something that
leads to a false sense of security. If you don't want your unsafe code
to be reliant on safe code, don't call that safe code, or be
conservative and defend yourself against it going wrong. Unsafe code
should be simple and easy to understand, and in practice this has
worked well so far.
Such a tool would be useful and would help evaluate the unsafe code
for correctness, but let's not pretend that it's needed for Rust to be
much safer than C++. However that is determined, if the unsafe code is
correct, all the safe code is guaranteed to be free from memory safety
problems. Action-at-a-distance (unmarked code affecting safe code) is
an unfortunate hazard, and one that we should mitigate, but in
practice changing safe code hasn't affected much, because our unsafe
code tends to be small and localized.
Patrick
Daniel Micay <danielmi...@gmail.com> wrote:
On 03/03/14 08:54 PM, Patrick Walton wrote:
On 3/3/14 5:53 PM, Daniel Micay wrote:
On 03/03/14 08:19 PM, Steve Klabnik wrote:
Part of the issue with that statement is that you may
or may not program in this way. Yes, people choose
certain subsets of C++ that are more or less safe, but
the language can't help you with that.
You can choose to write unsafe code in Rust too.
You have to write the *unsafe* keyword to do so. Patrick
You need an `unsafe` keyword somewhere, but the memory safety bug can
originate in safe co
de. Any
safe code called by unsafe code is trusted
too, but not marked as such. A memory safety bug can originate
essentially anywhere in librustc, libsyntax, libstd and the other
libraries because they're freely mixed with `unsafe` code.
It's pretty much a false sense of security without tooling to show which
code is trusted by an `unsafe` block/function *somewhere*, even in
another crate.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
