From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LoNZw-0005Cj-Sa for qemu-devel@nongnu.org; Mon, 30 Mar 2009 15:55:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LoNZs-00058q-7P for qemu-devel@nongnu.org; Mon, 30 Mar 2009 15:55:28 -0400 Received: from [199.232.76.173] (port=57357 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LoNZr-00058e-MJ for qemu-devel@nongnu.org; Mon, 30 Mar 2009 15:55:23 -0400 Received: from mx2.redhat.com ([66.187.237.31]:42260) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LoNZr-0008Vs-6B for qemu-devel@nongnu.org; Mon, 30 Mar 2009 15:55:23 -0400 Message-ID: <49D123CE.8060007@redhat.com> Date: Mon, 30 Mar 2009 22:55:58 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Document Qemu coding style References: <1238361823-24939-1-git-send-email-avi@redhat.com> <20090330.130212.1723234361.imp@bsdimp.com> In-Reply-To: <20090330.130212.1723234361.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: blauwirbel@gmail.com M. Warner Losh wrote: > In message: > Blue Swirl writes: > : > +An exception is the opening brace for a function; for reasons of tradition > : > +and clarity it comes on a line by itself: > : > + > : > + void a_function(void) > : > + { > : > + do_something(); > : > + } > : > + > : > +Rationale: a consistent (except for functions...) bracing style reduces > : > +ambiguity and avoids needless churn when lines are added or removed. > : > +Furthermore, it is the Qemu coding style. > : > : No, this is the K&R style. Quoting linux/Documentation/CodingStyle: > : > : Heretic people all over the world have claimed that this inconsistency > : is ... well ... inconsistent, but all right-thinking people know that > : (a) K&R are _right_ and (b) K&R are right. Besides, functions are > : special anyway (you can't nest them in C). > > And besides, there's lots of almost-smart tools that operate on source > code that know this is always true... Or at least historically that's > been the case, don't know of any widely used ones today, but I doubt > they were all fixed... > Relax, no one wants to change this... -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.