4 ms·

Even in this environment, you can still have dangling pointers to freed stack frames. There's no way around having a proper lifetime system, or a GC, if you wan

Even in this environment, you can still have dangling pointers to freed stack frames. There's no way around having a proper lifetime system, or a GC, if you want memory safety.

verdagon 4y ago
Yep, or generational references [0] which also protect against that kind of thing ;) The array-centric approach is indeed more applicable at the high levels of the program. Sometimes I wonder if a language could use an array-centric approach at the high levels, and then an arena-based approach for all temporary memory. Elucent experimented with something like this for Basil once [1] which was fascinating. [0] https://verdagon.dev/blog/generational-references https://verdagon.dev/blog/generational-references [1] https://degaz.io/blog/632020/post.html https://degaz.io/blog/632020/post.html
- com2kid 4y ago
  > Yep, or generational references [0] which also protect against that kind of thing ;) First off, thank you for posting all your great articles on Vale! Second off, I just read the generational references blog post for the 3rd time and now it makes complete sense, like stupid obvious why did I have problems understanding this before sense. (PS: The link to the benchmarks is dead :( ) I hope some of the novel ideas in Vale make it out to the programming language world at large!
  - verdagon 4y ago
    Thank you! I just fixed the link, thanks for letting me know! And if any of my articles are ever confusing, feel welcome to swing by the discord or file an issue =) I'm pretty excited about all the memory safety advances languages have made in the last few years. Zig is doing some really interesting things (see Andrew's thread above), D's new static analysis for zero-cost memory safety hit the front page yesterday, we're currently prototyping Vale's region borrow checker, and it feels like the space is really exploding. Good time to be alive!
- yw3410 4y ago
  It feels like it would work really well (you could even swap between arenas per frame). I've been wanting to try something similar but it's early days.
im3w1l 4y ago
Well if get rid of not just the heap, but the stack too... turn all variables into global ones, then it will be safe. This means we lose thread safety and functions become non-reentrant (but easy to prove safe - make sure graph of A-calls-B is a acyclical).
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 ago
    Your 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?

Even in this environment, you can still have dangling pointers to freed stack frames. There's no way around having a proper lifetime system, or a GC, if you want memory safety.

verdagon 4y ago

Yep, or generational references [0] which also protect against that kind of thing ;) The array-centric approach is indeed more applicable at the high levels of the program. Sometimes I wonder if a language could use an array-centric approach at the high levels, and then an arena-based approach for all temporary memory. Elucent experimented with something like this for Basil once [1] which was fascinating. [0] https://verdagon.dev/blog/generational-references https://verdagon.dev/blog/generational-references [1] https://degaz.io/blog/632020/post.html https://degaz.io/blog/632020/post.html

com2kid 4y ago
> Yep, or generational references [0] which also protect against that kind of thing ;) First off, thank you for posting all your great articles on Vale! Second off, I just read the generational references blog post for the 3rd time and now it makes complete sense, like stupid obvious why did I have problems understanding this before sense. (PS: The link to the benchmarks is dead :( ) I hope some of the novel ideas in Vale make it out to the programming language world at large!
- verdagon 4y ago
  Thank you! I just fixed the link, thanks for letting me know! And if any of my articles are ever confusing, feel welcome to swing by the discord or file an issue =) I'm pretty excited about all the memory safety advances languages have made in the last few years. Zig is doing some really interesting things (see Andrew's thread above), D's new static analysis for zero-cost memory safety hit the front page yesterday, we're currently prototyping Vale's region borrow checker, and it feels like the space is really exploding. Good time to be alive!
yw3410 4y ago
It feels like it would work really well (you could even swap between arenas per frame). I've been wanting to try something similar but it's early days.

im3w1l 4y ago

Well if get rid of not just the heap, but the stack too... turn all variables into global ones, then it will be safe. This means we lose thread safety and functions become non-reentrant (but easy to prove safe - make sure graph of A-calls-B is a acyclical).

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 ago
  Your 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?