Re: Changes to varobj.c

[Nick Roberts <nickrob@snap.net.nz>]

 > I think you've missed it. The patch was posted here:
 > 
 > 	http://article.gmane.org/gmane.comp.gdb.patches/40822
 > 
 > and the version I've checked in has no changes relative to the one
 > I've posted.

It looks like it was attached in reply to a patch with the subject header
"[RFC][patch 0/9] Python support in GDB".  I don't read everything posted to
gdb-patches and delete messages based on the subject which is why I must have
missed this one.

 > Would you like to CC-d on all MI patches?

If you just give an indication in the subject header about the content, as you
have suggested, that should be enough - thanks.

 > > I can see a stale comment before varobj_update:
 > > 
 > >    NOTE: This function may delete the caller's varobj. If it
 > >    returns TYPE_CHANGED,...
 > > 
 > > (varobj_update no longer returns TYPE_CHANGED)
 > 
 > You are right. On the other hand, why do delete varobj when its type
 > changes, or in other words, why value_of_root uses varobj_create? I think
 > I'll just stop it making do so, 

If floating varobjs are used then var->root->exp changes when the frame changes
and using varobj_create is one way to get hold of this expression.  I think if
you don't use varobj_create then you will have to use a chunk of it.

 >                                together with the other planned change of
 > making -var-create of floating varobj not fail when the expression cannot be
 > parsed.

That's an independent matter though, right?

-- 
Nick                                           http://www.inet.net.nz/~nickrob


PS I've just noticed that:

  struct varobj **cv;
  struct varobj **templist = NULL;

are no longer used in varobj_update.

I've updated my linked list patch to your changes and it looks cleaner.  Using
a vector for result seems like a good idea, I just don't think it works for
varobj_list_children.