For example: a common pattern in video games is the frame-local allocation. You (cheaply) allocate some object at the beginning of a frame. Share references to it all over the place. At the end of the frame, you (cheaply) free all the objects that were allocated in this manner. This cannot really be expressed in terms of rust's ownership system.
More generally, rust enforces local correctness, while c allows for global correctness (a weaker condition). Consider, as a simpler example, this c function which I write frequently:
char *tmpstr(void) {
static char buf[16][1024];
static int i = 0;
char *ret = buf[i];
i = (i+1) % 16;
return ret;
}
Rust requires that every function be locally correct. Papering over some details: for any sound function f and hole-containing program P[_], if P[f] is well-typed then P[f] is sound; that means that it's always meaningful to consider f without considering the context in which it will be called. There is no such guarantee in c.
As a sound language, this is a very useful attribute for rust to have, because it means that libraries can be meaningfully type-checked (not to mention it significantly simplifies the type system), but it would be naive to say that rust simply formalizes the ownership model you would have used anyway in c.
Your function is easy to write in (unsafe!) Rust:
https://play.rust-lang.org/?version=stable&mode=debug&editio...
use lazy_static::lazy_static; // 1.4.0
use std::mem;
lazy_static! {
static ref BUF: [String; 16] = [
String::with_capacity(1024), String::with_capacity(1024), String::with_capacity(1024), String::with_capacity(1024),
String::with_capacity(1024), String::with_capacity(1024), String::with_capacity(1024), String::with_capacity(1024),
String::with_capacity(1024), String::with_capacity(1024), String::with_capacity(1024), String::with_capacity(1024),
String::with_capacity(1024), String::with_capacity(1024), String::with_capacity(1024), String::with_capacity(1024)
];
static ref BUF_INDEX: usize = 0;
}
fn tmpstr() -> &'static mut String {
let index_ptr: * const usize = &*BUF_INDEX;
let index: &'static mut usize = unsafe { mem::transmute(index_ptr) };
let buf_ptr: * const String = &BUF[*index];
let ret: &'static mut String = unsafe { mem::transmute(buf_ptr) };
ret.truncate(0);
*index = (*index + 1usize) % BUF.len();
return ret;
}
fn main(){
let s1 = tmpstr();
s1.push_str("Hello, world!");
let s2 = tmpstr();
s2.push_str("And hello world again!");
dbg!(s1, s2);
}
The difference between Rust and C in terms of memory model isn't ownership, it's “mutable xor shared”.
It's possible to use pointers to circumvent the restriction and then control when object is destructed using ManuallyDrop[0], so burden of memory bookkeeping will be shifted from Rust compiler to the programmer.
[0]: https://doc.rust-lang.org/core/mem/struct.ManuallyDrop.html
Can you just declare a static array and return a pointer pointing to any part of it? Like in the C example?
BUF is also visible to other parts of the program, correct? If so, it's not quite similar to the C example.
Indeed:
lazy_static! {
static ref BUF: [[u8;1024]; 16] = [
[0;1024], [0;1024], [0;1024], [0;1024],
[0;1024], [0;1024], [0;1024], [0;1024],
[0;1024], [0;1024], [0;1024], [0;1024],
[0;1024], [0;1024], [0;1024], [0;1024]];
static ref BUF_INDEX: usize = 0;
}
> BUF is also visible to other parts of the program, correct? If so, it's not quite similar to the C example.
No, because it's not marked as `pub`, nobody outside the current module can access it.
Yes, of course. BTW: You can use a c2rust converter to convert a C code to it exact equivalent in Rust.
No, buf is not exported, so it's "static" in C terminology.
Yes, I know that is not exported. What I wanted to say is that in the C example, no one outside tmpstr(void) can access static char buf[16][1024].
In the Rust example I can access static ref BUF from fn main() function, for example.
Only because in that simple example, BUF was defined directly in the main module.
In a more realistic exemple, BUF and tmpstr would belong to their own module, with only tmpstr being exported (and then accessible). See: https://play.rust-lang.org/?version=stable&mode=debug&editio...
Because C does not have lifetimes at all, or ownership as a formal langage concept, and thus does not run head first into the completeness problem.
Which is one of unsafe’s use cases: when the compiler can’t prove the code is correct (because there will always be correct programs the compiler can’t prove, and there are currently a fair bit of them), and you can, and there are no suitable safe alternatives, you use unsafe.
> For example: a common pattern in video games is the frame-local allocation. You (cheaply) allocate some object at the beginning of a frame. Share references to it all over the place. At the end of the frame, you (cheaply) free all the objects that were allocated in this manner. This cannot really be expressed in terms of rust's ownership system.
Of course it can, though it requires APIs which are not there (in the stdlib, yet): a frame local allocator and custom per-object allocator. All frame-local objects use that and thus keep a reference to the allocator.
And it avoids storing frame-local objects in locations which outlive the frame.
> This function is not locally correct; in a vacuum, it is impossible to say whether this function violates invariants.
That is also a use-case for unsafe: an unsafe function is one for which the caller is responsible for checking invariants.
This is unsafe anyway because modifying globals is unsafe to start with.
> Of course it can
You cannot share objects using rust's ownership system.
Interior mutability involves an unacceptable performance hit (and doesn't actually allow you to share anything). And if you use shared indices into a centralized array, then you have blinded the ownership system, creating pointers that it cannot make sense of.
>> This function is not locally correct; in a vacuum, it is impossible to say whether this function violates invariants.
> That is also a use-case for unsafe: an unsafe function is one for which the caller is responsible for checking invariants.
That's exactly right, and was my thesis; rust's type system does not allow you to prove the correctness of such a function, because it is neither correct nor incorrect without context. 'Unsafe', as a subversion of the type system which allows unsound behaviour, is completely uninteresting wrt the topic at hand; the comparison is a purely theoretical one between non-'unsafe' rust—that is, rust's ownership model—and c.
Unsafe does not allow unsound behavior, or rather, it lets you write unsound behavior but that is a bug. You still have to uphold various invariants in unsafe code. It’s there for when you know you can, but the compiler cannot, which is an inherent property of any sound system.
I don't understand what you're saying here.
Rust-without-'unsafe' is a sound language; i.e. any program which types will be unable to violate runtime invariants.
Rust-with-'unsafe' is an unsound language; i.e. there are programs which type but yet violate runtime invariants.
That is a bug in those programs—sure, yes, of course. It is not a bug in rust; it is the language functioning as intended. However the topic at hand is the relationship between rust's type system and c's; hence unsafe is completely uninteresting, because it is a tool for subverting rust's type system.
(It occurs to me now that I might have gotten a less generally defensive response had I made the original comparison between rust and a hypothetical rust without unsafe. Oh well)
Gotcha, I was just trying to clarify the semantics of unsafe, lots of people think it suddenly lets you do whatever you want, and while it will let you, that doesn't mean that you can, which is an important distinction. You're right that this puts it in the same general category of C in a theoretical perspective, I think practice will bear out that it's not a binary proposition, but time will tell :)
C is like a laser gun in a room full of oddly-shaped mirrors with no safety at all. Good luck.
That's what type systems in general do. There is no type system for a turing-complete language that is both sound and complete. (Trivial proof: if (undecidable) halt; unsound.)
For the record, the “topic at hand” was the memory model not the type-system, nor the theorem proving capabilities of the borrow checker.
Your arguments are not wrong per se, but they are completely missing the topic.
So here's another, hopefully better expression:
Rust's type system wrt lifetimes is not very expressive, compared with 'dynamically-typed' c. It can't represent things like 'the value returned by this function must remain alive for no more than 15 successive invocations of this function'.
Primitive pin tester for Arduino in 1kb: https://github.com/vlisivka/rapt
And Rust doesn't assume threading either. The default stuff isn't even thread safe, it's just that in Rust when you introduce threading and still try to use stuff that isn't thread safe the compiler will tell you that can't work.
You can deliberately write stuff that won't do what you meant of course, but they're trying to make it harder to do that by accident. I have a set of Rust types which defy logical behaviour (for example type whose members always compare as equal yet hash differently) and as intended if you use those in otherwise safe code your program might not work but it doesn't cause random craziness. For example maybe your attempt to binary search an ordered list of my data types that claim they form a total order and yet always reply "I'm smaller" when asked how they compare to anything, even themselves - will become an infinite loop, but it won't suddenly execute environment variables as code or anything like that whereas in C all bets are off.
Right, and Rust doesn't even know what a thread is actually. It's all implemented in the standard library. The only thing Rust know, is that there exist some special Traits (Send and Sync) which are automatically implemented if a struct field implements it itself. And that's it.
Rc and Arc are maintaining the “be sure that you'll only free this once” invariant automatically. In C you have the same invariant, you just have have to maintain it by yourself (or use an ad hoc reference counting mechanism) and if you don't it's a double free (UB). And in both cases you are responsible ensure the memory is freed at least once.
Mutex ensure you don't perform one read and one write at the same time. This is also forbidden by the C memory model and you'll probably end up using a mutex too (or other concurrency primitives) with the exact same risk of deadlock.