Re: [Gnash-dev] GC: status report & call for test

[Eric Hughes]

At 09:28 PM 7/6/2007, you wrote:
> We're still talking about non-intrusive flavors of this pointers I guess,
> which would mean reviewing the whole code base to *never* pass dumb
> pointers around, right ?

Yes.  And I _did_ say premature.

As for reviewing the whole code base, yes, it's a bunch of effort, and yes, 
it will be necessary for a good long term solution.  This is, however, can 
be made significant easier than mere brute force.  The simple idea is to 
overload operator& (address-of) and have it return some kind of not-dumb 
pointer.  The compiler will gladly inform you of your type mismatch.  The 
type that operator& returns might be just a wrapper around a dumb pointer 
with no extra functionality, but it can also be the type passed to 
constructors of the smart pointer classes.

        template< class T >
        class inchoate_ptr
        {
                T * the_pointer ;
        public:
                explicit inchoate_ptr( T * x ) : the_pointer( x ) {}
                friend gc_ptr ;
                friend rc_ptr ;
        } ;

        class something
        {
        public:
                inline inchoate_ptr< something > operator&() const { 
return inchoate_ptr< something >( this ) ; }
        } ;

        template< class T >
        class gc_ptr
        {
        public:
                gc_ptr( inchoate_ptr< T > x ) ;
        } ;

Make sure the constructor of inchoate_ptr is explicit to avoid accidental 
conversions outside of the class declaration.  Also, there must not be a 
conversion operator or a get() method that allows arbitrary access to the 
raw pointer.  I've omitted what gc_ptr, etc., would do, but essentially 
they just go in and grab the underlying pointer value and use it how they 
will.  Presumably we'll trust them to do the right thing.

The idea of inchoate_ptr<> is that of a transfer class, whose only purpose 
is to move data from one place to another in a strict channel from which 
nothing escapes and into which nothing enters.  This enables good 
maintenance of invariants, which in this case are something like "every 
pointer to this class is under memory management".

This is a good permanent tactic for preventing such problems in the 
future.  It's a simple idea, but that doesn't mean it's a small amount of 
work.  One advantage, however, is that you can convert over class-by-class 
rather than having some red flag day.

Although this message is already a little long, I note in passing that I'd 
use a second transfer class to deal with using auto-allocated objects as 
initializers for managed objects.  It would take an inchoate_ptr<> as a 
constructor parameter and the type would carry the property "my storage is 
allocated on the stack".  Constructors to gc_ptr, etc., could then perform 
appropriate reallocation when needed.

Eric