7 ms·

There are generally four approaches to memory safety: [...] Reference counting (RC), like in Swift, Nim, Lobster, etc. Reference Counting by itself doe

There are generally four approaches to memory safety: [...] Reference counting (RC), like in Swift, Nim, Lobster, etc. Reference Counting by itself does not provide memory safety, as it cannot handle cyclic references, which would lead to memory leaks in any sufficiently complex program. I don't have direct experience in any of the mentioned languages, but I seriously doubt they use Reference Counting as a sole mechanism for managing memory.

Xylakant 4y ago
Rust provides explicit mechanisms to leak memory and its notion of memory safety does not include “never leaks” . A rust program that leaks memory like a sieve is considered safe.
norman784 4y ago
I think weak references solves that issue. > A weak reference is a reference that doesn’t keep a strong hold on the instance it refers to, and so doesn’t stop ARC from disposing of the referenced instance. [0] [0] https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html https://docs.swift.org/swift-book/LanguageGuide/AutomaticRef...
- bheadmaster 4y ago
  They would solve the issue only if the language itself forbid the programmer from creating cyclic strong references. If that's the case, then I was wrong in my original comment. Although the thought of forbidding arbitrary references feels a little restrictive to me - it would be placing the burden of keeping a tree of references onto the programmer. I don't know how well that works in practice. Perhaps trying out some of the mentioned languages would be insightful.
masklinn 4y ago
> which would lead to memory leaks in any sufficiently complex program. Memory leaks (and more generally resource leaks) are not generally considered memory safety issues. After all, that's basically what an advanced GC manages for you: you leak memory, and it tries to clean up after you. But whether it does is entirely up to it and its configuration (nothing precludes disabling it and leaking all the memory, there's nothing actionable at the language level).
- deleted 4y ago
  [deleted]
scaredginger 4y ago
You have a point, but memory leaks generally aren't considered as problematic as other memory issues, such as buffer overruns and use after free. While they can cause programs to crash and degrade, they generally don't corrupt program data or lead to security vulnerabilities. As such, people often don't include protection from memory leaks as a criterion for 'memory safety'. It's possible to explicitly leak memory in the safe subset of Rust (e.g. Box::leak). It's also possible to 'leak' memory in GC'd languages too by keeping old references around you'll never use, although this example is just arguing semantics even more.
- bheadmaster 4y ago
  > memory leaks generally aren't considered as problematic as other memory issues, such as buffer overruns and use after free. [...] they generally don't corrupt program data or lead to security vulnerabilities. I see. Although that definition of safety feels a little wrong to me, I can't think of any security issue that could be caused by a memory leak. Perhaps OOM killer butchering random processes on the system, bringing it to some vulnerable state? But then again - that's a system failure, as any well-behaved process might as well use more memory than is available.
  - hedora 4y ago
    Safety usually means the program isn’t doing something wrong. You are thinking of liveness, which means the program continues to do something good. If killing a process leaves the system in an unsafe state, that’s probably not the fault of the OOM killer. (What if the killed process was slow to start, or failed an assert and exited instead?)
jerf 4y ago
It can depend on your precise definition of "safe". If you define it in terms of accessing correct memory, leaked memory may be inconvenient, it may be "incorrect", but it is safe. It is not, on its own, a security issue (other than eventually leading to possible program termination due to resource exhaustion, which is considered a security issue but I've always thought of this as generally "just barely" in the security class of issue). It may be chained into one if some other bug allowed access to it, but that "some other bug" would itself be the memory unsafe bug.
- skohan 4y ago
  It may not even be incorrect. For instance if the only thing you care about is raw speed, an allocator which just grabs pages of memory and never deallocates or overwrites might be the optimal solution, especially if it's provable allocations will never grow beyond a certain upper limit.
cb321 4y ago
Nim is choice, including choice among a variety of memory management options including manual, markAndSweep style collection, reference counting variants, etc.

Xylakant 4y ago

Rust provides explicit mechanisms to leak memory and its notion of memory safety does not include “never leaks” . A rust program that leaks memory like a sieve is considered safe.

norman784 4y ago

I think weak references solves that issue. > A weak reference is a reference that doesn’t keep a strong hold on the instance it refers to, and so doesn’t stop ARC from disposing of the referenced instance. [0] [0] https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html https://docs.swift.org/swift-book/LanguageGuide/AutomaticRef...

bheadmaster 4y ago
They would solve the issue only if the language itself forbid the programmer from creating cyclic strong references. If that's the case, then I was wrong in my original comment. Although the thought of forbidding arbitrary references feels a little restrictive to me - it would be placing the burden of keeping a tree of references onto the programmer. I don't know how well that works in practice. Perhaps trying out some of the mentioned languages would be insightful.

masklinn 4y ago

> which would lead to memory leaks in any sufficiently complex program. Memory leaks (and more generally resource leaks) are not generally considered memory safety issues. After all, that's basically what an advanced GC manages for you: you leak memory, and it tries to clean up after you. But whether it does is entirely up to it and its configuration (nothing precludes disabling it and leaking all the memory, there's nothing actionable at the language level).

deleted 4y ago
[deleted]

scaredginger 4y ago

You have a point, but memory leaks generally aren't considered as problematic as other memory issues, such as buffer overruns and use after free. While they can cause programs to crash and degrade, they generally don't corrupt program data or lead to security vulnerabilities. As such, people often don't include protection from memory leaks as a criterion for 'memory safety'. It's possible to explicitly leak memory in the safe subset of Rust (e.g. Box::leak). It's also possible to 'leak' memory in GC'd languages too by keeping old references around you'll never use, although this example is just arguing semantics even more.

bheadmaster 4y ago
> memory leaks generally aren't considered as problematic as other memory issues, such as buffer overruns and use after free. [...] they generally don't corrupt program data or lead to security vulnerabilities. I see. Although that definition of safety feels a little wrong to me, I can't think of any security issue that could be caused by a memory leak. Perhaps OOM killer butchering random processes on the system, bringing it to some vulnerable state? But then again - that's a system failure, as any well-behaved process might as well use more memory than is available.
- hedora 4y ago
  Safety usually means the program isn’t doing something wrong. You are thinking of liveness, which means the program continues to do something good. If killing a process leaves the system in an unsafe state, that’s probably not the fault of the OOM killer. (What if the killed process was slow to start, or failed an assert and exited instead?)

jerf 4y ago

It can depend on your precise definition of "safe". If you define it in terms of accessing correct memory, leaked memory may be inconvenient, it may be "incorrect", but it is safe. It is not, on its own, a security issue (other than eventually leading to possible program termination due to resource exhaustion, which is considered a security issue but I've always thought of this as generally "just barely" in the security class of issue). It may be chained into one if some other bug allowed access to it, but that "some other bug" would itself be the memory unsafe bug.

skohan 4y ago
It may not even be incorrect. For instance if the only thing you care about is raw speed, an allocator which just grabs pages of memory and never deallocates or overwrites might be the optimal solution, especially if it's provable allocations will never grow beyond a certain upper limit.

cb321 4y ago

Nim is choice, including choice among a variety of memory management options including manual, markAndSweep style collection, reference counting variants, etc.