From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lx7wf-00041E-Mj for qemu-devel@nongnu.org; Thu, 23 Apr 2009 19:03:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lx7wa-00040V-LU for qemu-devel@nongnu.org; Thu, 23 Apr 2009 19:03:04 -0400 Received: from [199.232.76.173] (port=51008 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lx7wa-00040P-He for qemu-devel@nongnu.org; Thu, 23 Apr 2009 19:03:00 -0400 Received: from mail2.shareable.org ([80.68.89.115]:50247) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lx7wZ-0005nr-Pk for qemu-devel@nongnu.org; Thu, 23 Apr 2009 19:03:00 -0400 Date: Fri, 24 Apr 2009 00:02:57 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [7234] Use a more natural order Message-ID: <20090423230257.GR13326@shareable.org> References: <20090423185308.GH3795@csclub.uwaterloo.ca> <20090423.131250.756905613.imp@bsdimp.com> <20090423192844.GJ3795@csclub.uwaterloo.ca> <20090423.134136.-135509976.imp@bsdimp.com> <20090423195553.GM3795@csclub.uwaterloo.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090423195553.GM3795@csclub.uwaterloo.ca> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lennart Sorensen Cc: blauwirbel@gmail.com, qemu-devel@nongnu.org Lennart Sorensen wrote: > On Thu, Apr 23, 2009 at 01:41:36PM -0600, M. Warner Losh wrote: > > Hmmm, see how tricky this style is? It is confusing computing the > > contrapositive to the expression you want to express. Or rather you > > aren't computing the contrapositive here, which is what got me into > > trouble. I usually don't make mistakes like this, and I made it in > > coming up with the example. > > I wouldn't be surprised if there were languages other than english where > the reverse would be the natural order, so I don't think your argument > is worth much there. I wouldn't be surprised either. But C is based on English, and most programmers probably use a lot of English thinking. Anyway, QEMU is definitely oriented around English as its main human language :-) > > I've fixed several bugs like this over the years from coders that > > thought this was a good way to program. > > > > if (1 < x) > > > > rather than > > > > if (x < 1) > > > > is the most common pattern I've had to fix. > > Then you were fixing the wrong problem. The problem isn't the order, > but simply that sometimes people get their logic backwards. The correct > fix would have been: > > if (1 > x) > > if in fact the logic was backwards. You missed the point entirely. *whoosh* The point is that when if (1 < x) where "1 > x" was would have been correct, is a _more likely mistake for most people to make_ than if (x < 1) because the latter is more familiar to most people. There is less cognitive translation getting in the way of seeing what it means and writing fluently. The actual bug fix is irrelevant. The only thing relevant is which style causes more mistakes. > > I find this argument unpersuasive when the compiler will already warn > > me about if (x = 0). > > Some compilers warn you. Not all do. An error from all compilers is > also far better than a warning from some compilers. You can make it an error with the only compiler that can build QEMU if you want. I haven't seen any compiler which doesn't warn about it in the last 10 years, except on machines which are more than 10 years old. > This is why people writing safety critical code in C require this order. > It is simply the safest choice. I have a coding style which forbids this "safest choice" on the grounds that it causes more mistakes than it avoids. Of course I never use compilers which don't warn about it. That would be really stupid - *especially* when writing safety critical code. If you ignore _any_ warning in such code you are in big trouble. Actually, these days for safety critical code it would be stupid not to use the more advanced code checking tools such as Sparse... -- Jamie