manual memory management

[H. S. Teoh]

On Wed, Jan 09, 2013 at 08:33:23AM +0100, Rob T wrote:
[...]
> There is a point being made here that is perfectly valid. There is a
> form of memory leak that a GC can never catch, such as when when
> memory is allocated and simply never deallocated by mistake due to a
> persistent "in use" pointer that should have been nulled but wasn't.

No form of memory management will be immune to programmer error. That's
plain impossible. You can write broken code in any language, under any
kind of memory management system. Short of going heapless, nothing is
going to help you here.

(Actually, even going heapless won't help you -- think of what happens
if you have a fixed-sized stack and forget to pop used-up elements. Yes
such a bug is way more obvious than a pointer that didn't get nulled,
but both are still just bugs.)


> In addition, the GC itself may fail to deallocated freed memory or
> even free live memory by mistake. I've seen bugs described to that
> effect.

I thought the idea was to make it so that SafeD is free from this kind
of problem (short of a bug in the GC itself) -- AFAIK, the GC freeing
live memory is caused by having XOR'ed pointers or other such tricks
that cause the GC to fail to detect the pointer to the memory. In
theory, SafeD should prevent this by not allowing unsafe operations on
pointers like XOR'ing. SafeD still has a long ways to go, though.


> There simply is no panacea to the memory leak problem. What
> a GC does do, is free the programmer from a ton of tedium, and even
> allow for constructs that would normally not be practical to
> implement, but it can never guarantee anything more than that.
[...]

Yes. I don't think there are many things in the programming world that
can be guaranteed. The compiler would have to be clairvoyant (not merely
pass the Turing test) to catch these sorts of errors.


T

-- 
To provoke is to call someone stupid; to argue is to call each other stupid.