Unsafe Rust: An Intro and Open Questions
1–10 of 34 posts
Re: Unsafe Rust: An Intro and Open Questions
#2Author here. I'm currently interning at Mozilla with the goal of writing the "advanced" companion to the TRPL (The Rust Programming Language book): TURPL (The Unsafe Rust Programming Language).
In the process I'll need to wrangle various members of the community -- particularly core team members -- to determine the things that we actually intend to guarantee in safe code, and what unsafe code is allowed to "do".
This post was intended to kick off that effort by:
* Making it clear that stuff is unclear
* Asserting my beliefs on what things should be
* Getting the whole internet mad at me so that they can explain what it should actually be
So, please, single file: Get Mad On The Internet At This Guy
Re: Unsafe Rust: An Intro and Open Questions
#3Author here. I'm currently interning at Mozilla with the goal of writing the "advanced" companion to the TRPL (The Rust Programming Language book): TURPL (The Unsafe Rust Programming Language). In the process I'll need to wrangle various members of the community -- particularly core team members -- to determine the things that we actually intend to guarantee in safe code, and what unsafe code is allowed to "do". This…
Thanks for the great article!
I think the most important point you make is that unsafety confounds local reasoning, requiring reasoning about all the possible interactions a block of code might have with everything else. One of my favorite things about (safe) Rust (and functional languages in general) is exactly this local reasoning capability that you give up in unsafe code. It's still not clear to me whether or not it's harder to write correct-in-all-cases unsafe Rust code than correct-in-all-cases C/C++/etc. code in general.
As I was reading, I was thinking it would be nice for crates.io to include an indication of "level of unsafety" for each crate, but then you went and pointed out that the naive metrics for it would be dependent on stylistic choices. I wonder if you could transform to a "minimally unsafe representation", at either the code or AST level, and evaluate that.
Looking forward to TURPL, and especially interested in learning more about how unsafe code interacts with destructors, which seem particularly fraught.
Re: Unsafe Rust: An Intro and Open Questions
#4Since you mentioned you didn't understand what LLVM's "in bounds" meant:
In general, LLVM semantics are largely derived from C and C++ in terms of undefined behavior (although some aspects, like signed overflow, are merely optional). The rule for "in bounds" means that pointers can only be manipulated to point to some address within the bounds of their object, or possibly the address just after the object (which cannot be dereferenced). A concrete example:
struct foo { int a; char b; int c[32]; } obj;
char ptr = &obj.b; char ptr2 = ptr + kerfuffle;
In this example, it is undefined behavior if kerfuffle is not in the range of [-sizeof(int), sizeof(obj) - sizeof(int)]. (e.g., ptr2 == &obj.c[32] is valid, but ptr2 == &obj.c[33] is not).
Re: Unsafe Rust: An Intro and Open Questions
#5Since you mentioned you didn't understand what LLVM's "in bounds" meant: In general, LLVM semantics are largely derived from C and C++ in terms of undefined behavior (although some aspects, like signed overflow, are merely optional). The rule for "in bounds" means that pointers can only be manipulated to point to some address within the bounds of their object, or possibly the address just after the object (which cann…
It was more a jab at LLVM's documentation in general ;)
But since you're claiming to understand LLVM docs:
* How does LLVM identify that a region of memory is "allocated" per the usage in the GEP docs. In particular it may be useful to mark special addresses as "allocated" for special marker objects that don't actually exist.
* Does "in bounds" extend to arrays? e.g. can I offset even further from a ptr to foo if it's in an array of foo?
Re: Unsafe Rust: An Intro and Open Questions
#6Since you mentioned you didn't understand what LLVM's "in bounds" meant: In general, LLVM semantics are largely derived from C and C++ in terms of undefined behavior (although some aspects, like signed overflow, are merely optional). The rule for "in bounds" means that pointers can only be manipulated to point to some address within the bounds of their object, or possibly the address just after the object (which cann…
That's also this tricky issue with C that's often ignored. If you have a nested array and take a pointer &foo[0][0], the only in bounds pointers are the pointers into the 0th subarray.
Re: Unsafe Rust: An Intro and Open Questions
#7This is important for anyone considering using Rust. I was mistaken about the meaning of Rust's safety guarantees before reading this.
Re: Unsafe Rust: An Intro and Open Questions
#8This is important for anyone considering using Rust. I was mistaken about the meaning of Rust's safety guarantees before reading this.
Care to elaborate as to what you thought they were?
Re: Unsafe Rust: An Intro and Open Questions
#9This is important for anyone considering using Rust. I was mistaken about the meaning of Rust's safety guarantees before reading this.
Care to elaborate as to what you thought they were?
Sure. First, thanks for the writeup. I had imagined that the Rust standard library used safe code all the way down. (Whatever that meant, I hadn't put all that much thought into it.) But as you state, "everything is built on top of unsafe."
So I guess my understanding after reading this is that I could, using only "safe" code, accidentally manipulate the Rust standard library to cause undefined behavior, it's just much more unlikely in Rust than in C++.
Re: Unsafe Rust: An Intro and Open Questions
#10Earlier quoted context omitted.
Care to elaborate as to what you thought they were?
Sure. First, thanks for the writeup. I had imagined that the Rust standard library used safe code all the way down. (Whatever that meant, I hadn't put all that much thought into it.) But as you state, "everything is built on top of unsafe." So I guess my understanding after reading this is that I could, using only "safe" code, accidentally manipulate the Rust standard library to cause undefined behavior, it's just mu…
One important guarantee of Rust though: If you manage to do that, this is a bug in Rust and it's not your fault.
And really, that's true of any "safe" language, right? Java, Ruby, Javascript, Python, whatever -- implementation errors mean your program will do crazy bad stuff, and we all have them.