[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC V2 05/10] libxl_json: introduce parser functions for builtin types
On Wed, 2014-04-23 at 12:14 +0100, Wei Liu wrote: > On Wed, Apr 23, 2014 at 11:42:42AM +0100, Wei Liu wrote: > > On Wed, Apr 23, 2014 at 11:31:19AM +0100, Ian Campbell wrote: > > > On Wed, 2014-04-23 at 11:19 +0100, Wei Liu wrote: > > > > On Wed, Apr 23, 2014 at 11:12:54AM +0100, Ian Campbell wrote: > > > > > On Wed, 2014-04-23 at 11:01 +0100, Wei Liu wrote: > > > > > > > > > > > The aformentioned "calloc" falls into #1 but not this one. > > > > > > > > > > > > My comment is a bit confusing. The comment here actually refers to > > > > > > all > > > > > > the malloc'ed memory in the loop, which will be freed by > > > > > > libxl_cpuid_dispose. > > > > > > > > > > You mean when the caller eventually gets rid of the result, or the > > > > > error > > > > > path here does it? > > > > > > > > > > > > > The former. Caller will regardlessly call dispose_fn of a type, wouldn't > > > > it? > > > > > > Hrm, I'm not sure what we expect the caller to do with the output of a > > > failed operation. I think I would expect that the failing operation > > > would clean up any partial result. Ian? > > > > > > It might be worth having a poke around and seeing what other libxl > > > functions do under these circumstances. > > > > > > > The way I see it is that in current libxl code, the caller , regardless > > Sorry I meant "xl code". It does look that way doesn't it. Lets go for consistency for sure! Any chance you could add a comment to a relevant section of libxl.h to describe this expectation (in the general case, not just for this interface)? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |