[libvirt] [PATCH python] override: Return NULL on python failure in getCPUModelNames

[Cole Robinson]

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