4 ms·

Nice article as always. I don't think I fully grok this stuff (in other languages I've read about too). Perhaps you can help me have some clarity of thought. 1

Nice article as always. I don't think I fully grok this stuff (in other languages I've read about too). Perhaps you can help me have some clarity of thought. 1. What should I do when I want to make a data structure like a doubly linked list or a graph - ie one where multiple pointers point to the same object? 2. Memory is only one kind of resource where ownership needs to be tracked. Others include file handles, network sockets etc. Can you comment on whether the OB mechanism solves the problem in general, or is mainly for memory tracking?

YawningAngel 7y ago
You could make the entire thing `const` and operate in a purely functional fashion - though this approach might be absurd in the context of systems programming (I can't claim to know as I've no background in the area whatsoever.
- twic 7y ago
  How do you make an immutable doubly linked list?
  - WalterBright 7y ago
    Build it, then cast it to immutable in @system annotated code.
renox 7y ago
From the article: use 'system' annotation (the equivalent of unsafe in Rust)
WalterBright 7y ago
1. This is, of course, a well known problem with an O/B system. The usual resolution is to a) use another data structure or b) hide the double linked list in @system code and use a safe interface to it. 2. It's a general solution (not limited to memory).
nickpsecurity 7y ago
There's an article that focuses on number one: https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/ I propose doing anything super hard and rare outside the general model. Make the doubly-linked list in whatever tool supports easy verification. Things like Why3 and solvers for separation logic. Run that object code through lots of testing with runtime checks for the specified behavior. If it passes, it's probably earned the right to be wrapped for use in the memory-safe code. This use case is also why I prefer more research funding to go to verified solvers than to manually-verified algorithms. They'll get more real-world use on hard problems. Well, that and test generators. They complement each other. The testing tools are more cost-effective, too.

YawningAngel 7y ago

You could make the entire thing `const` and operate in a purely functional fashion - though this approach might be absurd in the context of systems programming (I can't claim to know as I've no background in the area whatsoever.

twic 7y ago
How do you make an immutable doubly linked list?
- WalterBright 7y ago
  Build it, then cast it to immutable in @system annotated code.

renox 7y ago

From the article: use 'system' annotation (the equivalent of unsafe in Rust)

WalterBright 7y ago

1. This is, of course, a well known problem with an O/B system. The usual resolution is to a) use another data structure or b) hide the double linked list in @system code and use a safe interface to it. 2. It's a general solution (not limited to memory).

nickpsecurity 7y ago

There's an article that focuses on number one: https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/ I propose doing anything super hard and rare outside the general model. Make the doubly-linked list in whatever tool supports easy verification. Things like Why3 and solvers for separation logic. Run that object code through lots of testing with runtime checks for the specified behavior. If it passes, it's probably earned the right to be wrapped for use in the memory-safe code. This use case is also why I prefer more research funding to go to verified solvers than to manually-verified algorithms. They'll get more real-world use on hard problems. Well, that and test generators. They complement each other. The testing tools are more cost-effective, too.