3 ms·
> Even in this environment, you can still have dangling pointers to freed stack frames. How frequently does this happen in real software? I learned not to retu
by infamouscow 4y ago
> Even in this environment, you can still have dangling pointers to freed stack frames.
How frequently does this happen in real software? I learned not to return pointers to stack allocated variables when I was 12 years old.
> There's no way around having a proper lifetime system, or a GC, if you want memory safety.
If you're building an HTTP caching program where you know the expiration times of objects, a Rust-style borrow-checker or garbage collector is not helping anyone.
- Arnavion 4y ago>I learned not to return pointers to stack allocated variables when I was 12 years old. So, if you slip while walking today, does that mean you didn't learn to walk when you were one year old?
- infamouscow 4y agoYour analogy doesn't answer the question. How frequently does this happens in real software?
- seoaeu 4y ago> > Even in this environment, you can still have dangling pointers to freed stack frames. > How frequently does this happen in real software? I learned not to return pointers to stack allocated variables when I was 12 years old. This happens rarely. However, the reason it isn't an issue is because C programmers are (and have to be) extremely paranoid about this kind of thing. Rust, however, lets you recklessly pass around pointers to local variables while guaranteeing that you won't accidentally use one as a return value. One example is scoped thread pools which let you spawn a bunch of worker threads and then pass them pointers to stack allocated variables that get concurrently accessed by all the threads. The Rust type system/borrow checker ensures both thread safety and memory safety. Would you trust a novice C programmer to use something like that?