[libvirt] [PATCH python] override: Return NULL on python failure in getCPUModelNames
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; } #endif /* LIBVIR_CHECK_VERSION(1, 1, 3) */ -- 1.8.5.3
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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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
participants (2)
-
Cole Robinson -
Eric Blake