From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59040 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ok1HZ-00044d-FJ for qemu-devel@nongnu.org; Fri, 13 Aug 2010 16:55:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ok1HY-0002DR-2u for qemu-devel@nongnu.org; Fri, 13 Aug 2010 16:55:17 -0400 Received: from fe01x03-cgp.akado.ru ([77.232.31.164]:57637 helo=akado.ru) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ok1HX-0002Cx-Qe for qemu-devel@nongnu.org; Fri, 13 Aug 2010 16:55:16 -0400 Date: Sat, 14 Aug 2010 00:54:57 +0400 (MSD) From: malc Subject: Re: [Qemu-devel] [PATCH 0/5] CODING_STYLE amendments In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="33734824-1645086038-1281732897=:5681" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --33734824-1645086038-1281732897=:5681 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Fri, 13 Aug 2010, Blue Swirl wrote: > On Thu, Aug 12, 2010 at 6:56 PM, malc wrote: > > On Thu, 12 Aug 2010, Blue Swirl wrote: > > > >> Add a few rules, based loosely on libvirt HACKING. > >> > >> Blue Swirl (5): > >>   CODING_STYLE: add preprocessor rules > >>   CODING_STYLE: add C type rules > >>   CODING_STYLE: add memory management rules > >>   CODING_STYLE: add string management rules > >>   CODING_STYLE: add rules for printf-like functions > >> > >>  CODING_STYLE |  111 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>  1 files changed, 111 insertions(+), 0 deletions(-) > > > > While intentions of this are good, i believe this goes too far, i doubt > > that the proposed additions are enforcable and have no doubts that they > > will be widely ignored and at the same time provide more grounds for > > whining. > > Then, either we add some kind of enforcement or we downgrade the rules > to recommendations or guidelines. I'm fine with the latter. > > > Furthermore the existing code doesn't follow them, going out on > > a limb, it's more likely that one would look around the code he/she > > modifies and base his/her modifications on the surrounding code than to > > follow the style that conflicts with it. > > I'll try to remove the new stuff. > > On the other hand, it should be possible to introduce new rules in > general. We can explicitly state that old code does not follow this > rule, but patches to fix the problems are appreciated and immediately > applied. > > This also applies to the unfortunate situation with the braces rule, > which is constantly broken. -- mailto:av1474@comtv.ru --33734824-1645086038-1281732897=:5681--