6 ms·

This depends on the definition. Rust originally included leaks in their definition of unsafe and later changed the definition when they found out that they can

by uecker 4d ago

This depends on the definition. Rust originally included leaks in their definition of unsafe and later changed the definition when they found out that they can not reliably prevent leaks. Leaks could reasonably be considered unsafe as they can cause a program to crash due to resource exhausting, even where the actually used memory is limited. If you do not consider leaks as part of the problem, there is a trivial way to avoid use-after-free and double-free: Simply never free any memory or only at the very end. (Which in some scenarios is exactly what people do.) The later would fulfill your definition of "holding references to be able to free them".

tialaramex 4d ago
> Leaks could reasonably be considered unsafe as they can cause a program to crash due to resource exhausting, even where the actually used memory is limited. You can make this claim about any resource, there's no reason to single out memory here. You can run out of file descriptors, inodes, connections to a remote database, disk space, anything - including CPU time. And notice that it wasn't the leak that you've now said was unsafe, it was the use itself. The program didn't blow up "because of a leak", it blew up because we exceeded some arbitrary resource threshold which may have been invisible to us. > If you do not consider leaks as part of the problem, there is a trivial way to avoid use-after-free and double-free: Simply never free any memory Indeed. And that's exactly what we see in some domains and if you've solved the other issues (e.g. bounds misses, type confusion) you've now got memory safe programs. Most general purpose software can't be written this way, but there is a whole heck of a lot of software out there which could be. > The later would fulfill your definition of "holding references to be able to free them". And that former would be characterized as "leak everything" and indeed that's entirely safe and, just as I said, to an end user this is a distinction which makes absolutely no difference.
- uecker 4d ago
  Yes, other resource leaks can cause similar problems, this just does not have much to do with memory, so calling it "memory safety" would be strange. On the other hand, including "memory leaks" under "memory safety" makes a lot of sense, which is also why Rust did this initially. And, of course, if you look at garbage collection, then they really cared about this. To the end user memory leaks are not important as long as you do not exceed the available memory and the program does not crash. The moment it does, it a problem and it can be a risk. What I agree with, (if you argued that point - but you don't), is that it is more benign and qualitatively different risk than unbounded behavior you may get with an out-of-bounds access or use-after-free.

by uecker 4d ago

tialaramex 4d ago

> Leaks could reasonably be considered unsafe as they can cause a program to crash due to resource exhausting, even where the actually used memory is limited. You can make this claim about any resource, there's no reason to single out memory here. You can run out of file descriptors, inodes, connections to a remote database, disk space, anything - including CPU time. And notice that it wasn't the leak that you've now said was unsafe, it was the use itself. The program didn't blow up "because of a leak", it blew up because we exceeded some arbitrary resource threshold which may have been invisible to us. > If you do not consider leaks as part of the problem, there is a trivial way to avoid use-after-free and double-free: Simply never free any memory Indeed. And that's exactly what we see in some domains and if you've solved the other issues (e.g. bounds misses, type confusion) you've now got memory safe programs. Most general purpose software can't be written this way, but there is a whole heck of a lot of software out there which could be. > The later would fulfill your definition of "holding references to be able to free them". And that former would be characterized as "leak everything" and indeed that's entirely safe and, just as I said, to an end user this is a distinction which makes absolutely no difference.

uecker 4d ago
Yes, other resource leaks can cause similar problems, this just does not have much to do with memory, so calling it "memory safety" would be strange. On the other hand, including "memory leaks" under "memory safety" makes a lot of sense, which is also why Rust did this initially. And, of course, if you look at garbage collection, then they really cared about this. To the end user memory leaks are not important as long as you do not exceed the available memory and the program does not crash. The moment it does, it a problem and it can be a risk. What I agree with, (if you argued that point - but you don't), is that it is more benign and qualitatively different risk than unbounded behavior you may get with an out-of-bounds access or use-after-free.