Re: [PATCH 08/13 v5] libxl: don't leak ptr in libxl_list_vm error case [and 1 more messages]

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 13/12/2013 16:52, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 08/13 v5] libxl: don't leak ptr in libxl_list_vm error case"):
>> On Tue, 2013-12-03 at 14:29 +1300, Matthew Daley wrote:
>>> +    /*
>>> +  * Always make sure to allocate at least one element; if we don't and we
>>> +  * request zero, libxl__calloc (might) think its internal call to calloc
>>> +  * has failed (if it returns null), if so it would kill our process.
> [rewrapped -iwj]
>> Is size==0 something we could/should handle in our libxl__*alloc
>> wrappers?
> I think so.  I think they should promise that if you pass size==0 you
> get a non-null pointer.  Calling realloc with size==0 should crash.

Can we not?

Having a non-NULL pointer to a 0 length buffer is madness, whose use
should not be further encouraged.

Furthermore, code which ends calling libxl__*alloc() with a size of 0
*is* buggy, and should suffer an abort(), just as much as attempting to
realloc to a size of 0.

>
> Matthew Daley writes ("Re: [PATCH 08/13 v5] libxl: don't leak ptr in libxl_list_vm error case"):
>> Ping?
> See Ian C's comment above, which AFAICT hasn't been answered.
>
> Thanks,
> Ian.

I believe I suitably answered that question, and justified why it had to
stay.

There is an API difference between returning NULL (Call to list domains
failed), and non NULL but with nb_domains = 0 (Call to list domains
succeeded but there are no domains).

~Andrew