5 ms·
Oops, I meant to write pointer conversion, not dereferencing. Yes, I read the paper, as I was taking that directly from the Rust code shown in the paper. The u
by rbehrends 9y ago
Oops, I meant to write pointer conversion, not dereferencing. Yes, I read the paper, as I was taking that directly from the Rust code shown in the paper.
The underlying problem is that Rust's borrow checker cannot possibly capture at compile time the arbitrary relations between objects managed by a garbage collector and arbitrary object layouts. Whatever guarantees it provides, memory safety isn't one of them (and cannot be), even if nominally only part of it is unsafe code. Pointer arithmetic and memory safety do not mix.
What you get out of that is basically an alternative approach to information hiding, not memory safety.
- burntsushi 9y agoIt sounds like you're shifting the goal posts pretty dramatically to me. Compare what you said above (which presumably prompted the reference to this paper) > Writing a garbage collector runtime in Rust has most of the same problems in Rust as in C, because you have to write most of it in unsafe code, where Rust inherits much of C's undefined behavior w.r.t. pointers via LLVM. In short, you have largely the same problems and have added a hard dependency on Rust. to the conclusions drawn in the cited paper. They sit in pretty stark contrast from where I'm standing.
- rbehrends 9y agoI'm not sure where you're getting the "goal post shifting" from. Writing "p.plus(n)" in their Rust code is not materially different from what "p + n" would be in C/C++ code. That the former is nominally safe code doesn't change the fact that the same unsafe Rust code gets inlined at every callsite. You could do the same in C++ by creating an Address class (similar to smart pointers) with restricted operations; these operations would not magically become safer just because they're inlined by the compiler rather than spelled out in the code.