[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 2/2] python: return error if PyObject obj is NULL for unwrapper helper functions



On 04/17/2012 11:49 AM, Eric Blake wrote:
> On 04/17/2012 11:45 AM, Guannan Ren wrote:
>>     The result is indeterminate for NULL argument to python
>>     functions as follows. It's better to return negative value in
>>     these situations.
>>
>>     PyObject_IsTrue will segfault if the argument is NULL
>>     PyFloat_AsDouble(NULL) is -1.000000
>>     PyLong_AsUnsignedLongLong(NULL) is 0.000000
>> ---
>>  python/typewrappers.c |   26 +++++++++++++++++++++++---
>>  1 files changed, 23 insertions(+), 3 deletions(-)
> 
> ACK.

I spoke too soon.  On looking at it more, I'm wondering if all callers
do the right thing in this case.  It would probably be better if we
explicitly raised a python exception before returning -1, so that
callers can blindly assume that a return of -1 means that the correct
python error is already present.

That is, instead of:

if (!obj)
    return -1;

should we instead be doing something like:

if (!obj) {
    PyErr_SetString(PyExc_TypeError, "unexpected type");
    return -1;
}

Or are we guaranteed that the only way obj is NULL is if the caller
already encountered an error, so there is already a python error set?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]