From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: [PATCH RFC V2 05/10] libxl_json: introduce parser functions for builtin types Date: Wed, 23 Apr 2014 12:14:27 +0100 Message-ID: <20140423111427.GC7712@zion.uk.xensource.com> References: <1397733191-31892-1-git-send-email-wei.liu2@citrix.com> <1397733191-31892-6-git-send-email-wei.liu2@citrix.com> <1398179398.4880.51.camel@kazak.uk.xensource.com> <20140423100134.GX7712@zion.uk.xensource.com> <1398247974.18537.10.camel@kazak.uk.xensource.com> <20140423101930.GZ7712@zion.uk.xensource.com> <1398249079.18537.19.camel@kazak.uk.xensource.com> <20140423104242.GB7712@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20140423104242.GB7712@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Anthony Perard , ian.jackson@eu.citrix.com, Wei Liu , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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".