From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38107 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnRI7-0001ip-RP for qemu-devel@nongnu.org; Mon, 23 Aug 2010 03:18:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnRI4-0004n8-05 for qemu-devel@nongnu.org; Mon, 23 Aug 2010 03:17:59 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:42387) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnRI3-0004n2-P6 for qemu-devel@nongnu.org; Mon, 23 Aug 2010 03:17:55 -0400 Received: by qwh5 with SMTP id 5so4951091qwh.4 for ; Mon, 23 Aug 2010 00:17:55 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4C72209E.2080306@redhat.com> Date: Mon, 23 Aug 2010 09:17:50 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <4C6A4291.1020105@redhat.com> <4C6A8CD8.2080701@codemonkey.ws> <4C71550F.6080602@redhat.com> <4C716F43.8070805@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/5] CODING_STYLE amendments List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Jes Sorensen , Miguel Di Ciurcio Filho , Markus Armbruster , qemu-devel On 08/22/2010 08:56 PM, Blue Swirl wrote: > On Sun, Aug 22, 2010 at 6:41 PM, Anthony Liguori wrote: >> On 08/22/2010 11:49 AM, Jes Sorensen wrote: >>>>> >>>>> While wasting time for historical reasons is certainly better than >>>>> wasting time for the heck of it, it's arguably worse than stopping the >>>>> waste. >>>>> >>>> >>>> But how would you do that? Drop the CODING_STYLE (and accept >>>> anything)? Switch to a new CODING_STYLE that is widely appreciated and >>>> so all bikeshedding will cease? Enforce current style? >>>> >>> >>> I would suggest we either clean up the existing rule, or switch to the >>> Linux kernel style, with the explicit exemption that existing code can >>> keep the 4-char indentation, unless the whole file is converted. I'd >>> like to avoid a total reformatting of the codebase, but we could look at >>> it on a file by file base if it becomes relevant. >>> >> >> Why is this even still being discussed? What problem are people actually >> trying to solve? >> >> Can someone point to a bug in QEMU that's been caused because of >> CODING_STYLE or the fact that some patches don't adhere to it? > > 7b1df88f284f462ecb236931ad863a815f243195 This would have been caught just as well by -Wunreachable-code. We don't enable it and GCC manual discourages it, but it would be worthwhile checking how many false positives it gives in QEMU. I'm also quite surprised that the QEMU coding standards allow return-with-value when the value is void: if (hdr->data[0] & 1) { if (len != 4) /* TODO: Signal an error? */; return; return l2cap_sframe_in(ch, le16_to_cpup((void *) hdr->data)); } Paolo