From: Sean Middleditch <elanthis@...>
Date: 2002-03-08T14:09:17+09:00
Subject: Re: Talking Trash About Ruby

On Thu, 2002-03-07 at 23:39, Lyle Johnson wrote:
> All,
> 

snip

> 
> This is a big problem because the C++ object that this Data object
> refers to has in fact been destroyed by this point, and so the Ruby Data
> object has a "dangling" pointer. The code inside the mark function for
> this class assumes that the object hasn't been destroyed yet; after all,
> Ruby thinks it's still alive and so it must be OK. And we all know how
> ugly things can get when you try to dereference a dangling pointer.

How are these pointers getting freed?  The pointers should never ever be
freed until the Ruby objects using them are freed.  You can use the C
destructor function for Ruby objects to do this.

If this isn't possible (i.e. you have to destroy the C++ objects at a
certain time), then you should contain back pointers to the Ruby objects
(to unset their pointer) or something similar, to ensure there is never
a dangling pointer.

Your method is relying on the idea that the Ruby objects will be out of
scope.  This cannot be guaranteed, ever, since the programmer might make
some weird references to objects in their code.  And Ruby code should
never ever have the ability to crash the interpreter/host
app/extensions.

> 
> Lyle
>