Memory Safety without a GC or Ref Counting

[H. S. Teoh]

On Mon, Jan 21, 2013 at 06:37:36PM +0100, F i L wrote:
> So I've been thinking about this problem off and on for awhile, and
> I think I have a rather simple solution. I highly doubt I'm the
> first to think of it, but haven't found any info about a similar
> idea on the net. So in the interest of science I'm posting it here
> so anyone interested can attempt to poke holes in the idea, which
> you folks have been so good at in the past.
> 
> This isn't really D related, but I usually like the feedback I get
> from this community, plus, if there's any value in the idea, maybe
> it would be a worth while discussion for future directions D might
> make use of.
> 
> I'll be illustrating with Pseudo-code. The basic idea spawns from
> conceptually separating variables as either "memory owners" or
> "memory references". Basically, the pseudo-code has three types:
> 
> var - Memory Owner, never null, deleted at end of scope**
> ref - Memory Reference, can't "own" memory
> ptr - Unsafe manually managed memory pointer (like C pointers)
[...]

I invented this scheme (independently -- I'm sure the concept has been
thought of before) way back when I was coding in C and C++.

Of course, I didn't have language/compiler support, but I did adopt a
convention of marking every pointer with [O] (for owner) and [R] (for
reference) in comments, in all my code. Owner pointers can never be
assigned a reference pointer, and owner pointers can only be
destructively copied (the original must be set to NULL after copying).
Owner pointers must be free()'d if they are non-NULL and going out of
scope (unless they are returned from the function, in which case I
consider it as a conceptual destructive copy followed by NULLing). I did
allow owner pointers to be NULL -- mainly because it is required for
destructive copy to be sound.

In newer versions of C++ (I invented this scheme back in the 90's when
templates and STL were only starting to emerge), owner pointers are
essentially equivalent to STL's auto_ptr<T>.

This was essentially as far as I developed the concept -- and probably
it's as far as it will get, because the concept has limitations:

1) It required code to be manually written to deal with owner pointers
correctly (auto_ptr mostly made this automatic, but it is certainly NOT
a drop-in replacement for pointers);

2) It can't deal with cyclic structures correctly;

3) It is still unsafe: you can have a dangling reference to owned
memory, because the owner pointer goes out of scope and the memory gets
deallocated, but there can still be references lingering around
somewhere.

IOW, it doesn't solve the problem of memory management. It is one level
up from having no distinction whatsoever between pointers (and scarily
enough, I've seen "enterprise" code that was obviously written without
any such distinction in mind), for sure, but it's not much more than
that.


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs