On Mon, Mar 31, 2008 at 02:40:54PM +0100, Richard W.M. Jones wrote: > On Mon, Mar 31, 2008 at 08:49:12AM -0400, Daniel Veillard wrote: > > On Mon, Mar 31, 2008 at 08:12:19AM -0400, Daniel Veillard wrote: > > > On Mon, Mar 31, 2008 at 01:02:49PM +0100, Daniel P. Berrange wrote: > > > > We should at the very least NULL-ify the dom/net fields in the Error > > > > object associated with the Connection when we free the Domain/Network > > > > object. > > > > > > agreed, very simple test but avoids dandling pointers. > > > > My patch for this. it's a bit more complex because we also keep a > > global variable for the last variable, and that needed to be exported to > > the hash module, it's still rather simple, > > Yes, ack from me too. > > I'm still going to deprecate these in the OCaml bindings, or maybe > just change them so you can only do physical pointer comparisons. I > just can't see a real life use for them ... You already know which > call failed and from that what domain it was operating on, so except > perhaps in the case of migration there is no new information here. > Also I've not seen any libvirt program yet which does more than just > print the error message and either abort or ignore it. I just looked at the python binding, and it doesn't even bother to copy the dom/net fields from virErrorPtr into the python layer - just completely ignores them. Similarly I don't bother to do anything with them in the Perl bindings. IMHO, we should just mark them as deprecated in the API docs & tell people not to use them. Note, we don't even have the virStoragePoolPtr or virStorageVolPtr objects in the error either. Regards, Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list