[Qemu-devel] Re: [PATCH 0/5] CODING_STYLE amendments

[Paolo Bonzini]

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