On 08/22/2010 08:56 PM, Blue Swirl wrote:
On Sun, Aug 22, 2010 at 6:41 PM, Anthony Liguori<anth...@codemonkey.ws> 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
