From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48489) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzAtF-0005fE-Bk for qemu-devel@nongnu.org; Tue, 16 Jul 2013 15:26:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzAqp-0005Ni-6O for qemu-devel@nongnu.org; Tue, 16 Jul 2013 15:24:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1320) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzAqo-0005NZ-TW for qemu-devel@nongnu.org; Tue, 16 Jul 2013 15:23:55 -0400 Message-ID: <51E59E5B.8010301@redhat.com> Date: Tue, 16 Jul 2013 21:26:19 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1373998781-29561-1-git-send-email-lersek@redhat.com> <1373998781-29561-2-git-send-email-lersek@redhat.com> <87ehaymixh.fsf@codemonkey.ws> In-Reply-To: <87ehaymixh.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Anthony Liguori Cc: qemu-devel@nongnu.org, Luiz Capitulino 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. 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