On 03/20/2014 02:06 PM, Eric Blake wrote: > On 03/20/2014 11:58 AM, Cole Robinson wrote: >> Eric pointed this out on the last patch, but I pushed it before noticing >> his message. >> --- >> libvirt-override.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libvirt-override.c b/libvirt-override.c >> index 71e241e..2532400 100644 >> --- a/libvirt-override.c >> +++ b/libvirt-override.c >> @@ -2350,7 +2350,7 @@ done: >> >> error: >> Py_XDECREF(rv); >> - rv = VIR_PY_NONE; >> + rv = NULL; >> goto done; > > ACK. We probably have other code not quite doing the right thing; maybe > it's time to audit the code base. > > The rule of thumb (which took me some time to learn) is: > > If libvirt failed, we have a thread-local libvirt error set. Return a > non-NULL sentinel value (-1 or None, depending on whether the interface > normally returns an integer or a python struct) so that the wrapper code > will then raise a libvirt exception class object. > > If python failed, we either encountered OOM, or there was some other > problem with the user's input (perhaps the user passed in a python > object that can't be converted to the type we expect), and we don't have > any thread-local libvirt error set. Return NULL so that python will > immediately raise a python exception class object without even getting > to our wrapper. > > Returning NULL when there is no thread-local python exception ready to > raise, or returning non-NULL when there is no thread-local libvirt error > to convert to a libvirt exception object, or returning the wrong type of > sentinel, results in broken code. > Thanks for the explanation. I've pushed this patch now - Cole -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list