From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzBHX-0002sf-Tn for qemu-devel@nongnu.org; Tue, 16 Jul 2013 15:51:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzBHW-0004rl-SA for qemu-devel@nongnu.org; Tue, 16 Jul 2013 15:51:31 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:38688) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzBHW-0004rX-Mn for qemu-devel@nongnu.org; Tue, 16 Jul 2013 15:51:30 -0400 Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 16 Jul 2013 15:51:29 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id BE1526E803F for ; Tue, 16 Jul 2013 15:51:23 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r6GJpSLa125800 for ; Tue, 16 Jul 2013 15:51:28 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r6GJpSIm002233 for ; Tue, 16 Jul 2013 16:51:28 -0300 From: Anthony Liguori In-Reply-To: <51E59E5B.8010301@redhat.com> References: <1373998781-29561-1-git-send-email-lersek@redhat.com> <1373998781-29561-2-git-send-email-lersek@redhat.com> <87ehaymixh.fsf@codemonkey.ws> <51E59E5B.8010301@redhat.com> Date: Tue, 16 Jul 2013 14:51:26 -0500 Message-ID: <87ppuifflt.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 1/2] char: io_channel_send: don't lose written bytes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: qemu-devel@nongnu.org, Luiz Capitulino Laszlo Ersek writes: > On 07/16/13 20:57, Anthony Liguori wrote: >> Laszlo Ersek writes: >> >>> The g_io_channel_write_chars() documentation states, >>> >>> bytes_written: The number of bytes written. This can be nonzero even if >>> the return value is not G_IO_STATUS_NORMAL. [...] >>> >>> io_channel_send() could lose such bytes before. >>> >>> Furthermore, the (status == G_IO_STATUS_EOF) condition used to evaluate to >>> constant false whenever it was reached. When that condition actually held, >>> it always led to -1 / EINVAL. This patch (almost) distinguishes >>> G_IO_STATUS_EOF only when no bytes have been written, and then treats it >>> as an error. >> >> Just for my own benefit, I always assume G_IO_STATUS_EOF cannot happen >> if bytes_written > 0. I see what you mean by the comment but do you >> have any reason to believe this happens in practice? > > In my opinion, G_IO_STATUS_EOF doesn't make any sense whatsoever for a > write operation (for count>0) if glib kept any resemblance to write(), > and should never happen in practice. Okay, thanks! I'll give other folks a chance to look at this series and then apply in a day or so. Regards, Anthony Liguori > > The awkward commit message only captures the fact that I didn't forget > about G_IO_STATUS_EOF, I considered it explicitly. > >> Reviewed-by: Anthony Liguori > > Thanks! > > Laszlo