On Wed, Nov 30, 2011 at 06:26:18PM +0100, Christophe Fergeau wrote:
+ + if (!(old_node = gvir_config_xml_get_element(parent_node, child_name, NULL))) + return; + + /* FIXME: should we make sure there are no multiple occurrences + * of this node? + */ + xmlUnlinkNode(old_node); + xmlFreeNode(old_node); +}
I think we will get memory corruption if this API is combined with _attach_child:
And I'm wrong since the whole point of the introduction of GVirConfigXmlDoc is to avoid this kind of memory corruption. However, in the example below, fs_node will have a reference to a GVirConfigXmlDoc which has no relation with its GVirConfigObject::node pointer, and this pointer will be pointing to already freed memory which is suboptimal.
device_node = gvir_config_object_new("device"); fs_node = gvir_config_object_new("fs"); gvir_config_object_attach(device_node, fs_node); gvir_config_object_delete_child(device_node, "fs"); g_object_unref(G_OBJECT(fs_node));
The xmlNodePtr held by fs_node will be freed twice, once by _delete_child and when _finalize runs after the call to g_object_unref
Having each GVirConfigObject keep a list of its GVirConfigObject children would make it possible to handle this case I think.
I'm fine with getting this function in even if there are known issues with it.
Christophe