From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGvk8-0007gU-PN for qemu-devel@nongnu.org; Wed, 17 Jun 2009 10:04:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGvk3-0007g1-Nf for qemu-devel@nongnu.org; Wed, 17 Jun 2009 10:04:00 -0400 Received: from [199.232.76.173] (port=58438 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGvk3-0007fy-K9 for qemu-devel@nongnu.org; Wed, 17 Jun 2009 10:03:55 -0400 Received: from mx20.gnu.org ([199.232.41.8]:37055) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MGvk3-00017k-6e for qemu-devel@nongnu.org; Wed, 17 Jun 2009 10:03:55 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGvk2-0007v2-Ch for qemu-devel@nongnu.org; Wed, 17 Jun 2009 10:03:54 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH v3] avoid compilation warning/errors on up to date compilers/glibc Date: Wed, 17 Jun 2009 15:03:51 +0100 References: <28684080.110231245246057655.JavaMail.root@srv-05.w4a.fr> In-Reply-To: <28684080.110231245246057655.JavaMail.root@srv-05.w4a.fr> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906171503.52825.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: jcd@tribudubois.net > > This is no more correct than before. read() can return EINTR and that > > should be handled appropriately. Elsewhere, read() can return partial > > results and we ought to handle that properly. > > It handles all cases except EINTR. And in the actual code base EINTR and > __all other__ error cases are not handled. So as of today EINTR is not > handled propely (as well as all other error cases). So this consider EINTR > as an error when it could be handled in a nicer way. Previously no ERRORS > were considered as an error. What is best? The original is the lesser wevil because it is obviously wrong. Your patch looks like it does error handling and avoids generates warnings, but still does not work correctty. > > Using -D_FORTIFY_SOURCES=0 will eliminate these warnings. If we're > > going to fix these things, we should fix them properly. > > It just hides the problem and fix nothing but the compilation. Your patch just makes the bug more subtle and harder to spot. Paul