Re: [Texmacs-dev] [PATCH] solves GCC 3.2 auto_save segfault for me...

[Igor V. Kovalenko]

Joris van der Hoeven wrote:
> > > +//void destroy_tree_rep (tree_rep* rep);
> > >  inline tree::tree (const tree& x): rep (x.rep) { rep->ref_count++; }
> > > -inline tree::~tree () {
> > > -  if ((--rep->ref_count)==0) destroy_tree_rep (rep); }
> > > +
> > > +inline tree::~tree ()
> > > +{
> > > +    if ((--rep->ref_count)==0) {
> > > +        //destroy_tree_rep (rep);
> > > +        delete rep;
> > > +        rep = NULL;
> > > +    }
> > > +}
> >
> > I am a bit confused by this. Is this necessary?
> > We should recursively delete the tree,
> > so it does not suffice to just delete the pointer...
>
>
> I see now; that is the purpose of the virtual destructor...
>
> But now I am again confused, because the old routine
> destroy_tree_rep should precisely do the same thing
> as the virtual destructor. Apparently, a string is sometimes
> not a string or a compound not a compound...
>
> By the way, what is the effect of "rep = NULL" ?
> This is the only real change I can see,
> but I do not see why this should stabilize the code.

Well, I have ahabbit on nullifying the pointer just in case it is
dereferenced after the delete, so we catch the dereference.

In case of TeXmacs allocator the memory does not always get actually
freed after 'delete', so the dereference is still seems OK, when it's
really not.

So the stabilization effect is in that developer catch this early during 
testing.

> Maybe some destructor is called twice,
> like it has been the case with g++-3.0,
> and that the effect of your changes is to
> make this less disastrous. What happens if
> a virtual destructor is called for the NULL pointer?
> Is that just ignored?

Nope, it shouldn't get called. Do you think that deleting a NULL pointer is 
bad? :)


--
Regards,
Igor V. Kovalenko    mailto: iko at crec dot mipt dot ru