On Wednesday, 9 January 2013 at 18:46:53 UTC, Walter Bright wrote:
On 1/9/2013 9:26 AM, Rob T wrote:
For example, you can still access deallocated memory by
mistake,
If you're not playing with pointers, then this is a buggy GC.
Yes you are correct. I was thinking of nullable references when I
made that comment. When you dereference on a nulled reference, I
suppose that's not really referencing deallocated memory. I'm not
sure what exactly happens behind the scenes when you dereference
a null pointer, but obviously bad things happen and it's not
safe, also it is a memory related problem.
run out of
memory due to accumulating persistent pointers left around by
mistake,
Memory safety does not imply never running out of memory.
I did qualify what I said by mentioning that it depends on the
definition of memory safety. According to my definition of memory
safety, a memory leak is still a memory leak no matter how it
happens. I can however see an alternate definition which is
likely what you are suggesting, where so long as you are not
accessing memory that is not allocated, you are memory safe.
There must be more to it than that, so if you can supply a more
correct definition, that would be welcome.
or free memory that was not supposed to be freed by mistake.
Then it's a buggy GC.
Yes. The point however is that a GC can be buggy, so by having
one kicking around guarantees nothing unless you can prove that
the implementation is 100% correct.
I am reminded of the back up system that is less reliable than
the medium it is supposed to be protecting, or the power backup
supply that is less reliable than the main power grid.
My guess is that no one knows how good or bad a GC is relative to
what a manual system can do. The claims are likely the result of
anecdotal evidence alone. Has anyone actually done a
scientifically valid study that shows that a GC implementation is
statistically more reliable than a manual implementation?
Of course I understand that the lack of a scientific study proves
nothing either way, I'm simply pointing out that we're likely
making assumptions without any proof to back them up.
The GC implementation may
fail due to bugs, deallocating live memory or failing to
deallocate inactive
memory.
Of course memory safety presumes a correctly implemented GC.
Yes, of course, but this is a bit of a wild card since we
probably have no proof that any given GC implementation will be
correct.
The only thing a GC can do for you, is free up the programmer
from the tedium of
managing memory. It also allows constructs that otherwise
would be very
difficult or impractical to implement. The effect can be very
positive, but
there are no guarantees of memory safety.
This is incorrect - see above. A bug free GC, and not
"cheating" in using it, guarantees memory safety. This is a big
deal.
Yes and no. Yes if the definition excludes the ability to "leak
memory" due to programmer error, meaning allocating but failing
to deallocate - a GC cannot prevent this, only a programmer can.
I figure your definition excludes this kind of programmer error,
and that's OK with me.
I do however wonder about the ability to dereference null
pointers, specifically pointers that are considered to be
references. In D references are nullable, and I believe this is
considered safe.
-rt
