From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLZjf-0002Qz-Ik for qemu-devel@nongnu.org; Wed, 02 Nov 2011 08:16:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLZje-0002dV-Hc for qemu-devel@nongnu.org; Wed, 02 Nov 2011 08:16:03 -0400 Received: from lo.gmane.org ([80.91.229.12]:42423) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLZje-0002dQ-CT for qemu-devel@nongnu.org; Wed, 02 Nov 2011 08:16:02 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RLZjc-0006SE-Uy for qemu-devel@nongnu.org; Wed, 02 Nov 2011 13:16:00 +0100 Received: from 93-34-200-62.ip51.fastwebnet.it ([93.34.200.62]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Nov 2011 13:16:00 +0100 Received: from pbonzini by 93-34-200-62.ip51.fastwebnet.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Nov 2011 13:16:00 +0100 From: Paolo Bonzini Date: Wed, 02 Nov 2011 13:15:46 +0100 Message-ID: References: <1320175230-27980-1-git-send-email-ehabkost@redhat.com> <1320175230-27980-6-git-send-email-ehabkost@redhat.com> <20111102115641.GE29718@otherpad.lan.raisama.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <20111102115641.GE29718@otherpad.lan.raisama.net> Subject: Re: [Qemu-devel] [RFC PATCH 05/11] qemu_fclose: return last_error if set List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 11/02/2011 12:56 PM, Eduardo Habkost wrote: > No, if it's positive it won't be set on last_error, so we have to save > it somewhere other than last_error (that's what the qemu_close() return > value is used for). Ok, I was confused by your patch 6, which basically removes the only case when qemu_fclose was returning a positive, nonzero value. :) I guess the problem is there? > Without a separate function and qemu_file_set_if_error(), the function > will look like: > > int qemu_fclose(QEMUFile *f) > { > int ret = 0; > qemu_fflush(); > if (f->close) { > ret = f->close(f->opaque); > } > if (f->last_error) { ^^^^^^^^^^^^^ "if (ret >= 0 && f->last_error)" perhaps? > ret = f->last_error; > } > g_free(f); > return ret; > } > > > Now that I am looking at the resulting code, it doesn't look too bad. I > guess I was simply too eager to encapsulate every bit of logic (in this > case the "if (f->close) ..." part) into separate functions. I find the > two-function version slightly easier to analyze, though. Yes, it's the same for me too now that I actually understand what's going on. Paolo