[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH v4 2/3] ppc: Drop duplicated typedefs to be able t

From: Paolo Bonzini
Subject: Re: [Qemu-ppc] [PATCH v4 2/3] ppc: Drop duplicated typedefs to be able to compile with Clang in gnu99 mode
Date: Thu, 10 Jan 2019 21:35:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

On 10/01/19 17:00, Greg Kurz wrote:
>>> Hmm... so the choice here is to simply ignore the official coding
>>> style ?  
>> Are typedefs really our "official coding style"? It's mentioned in
>> HACKING, not in CODING_STYLE, so I rather see this as a recommendation
> Indeed.
>> only. (Otherwise, all the forward struct definitions at the beginning of
>> spapr.h are a plain violation of the coding style, too...)
> Yeah.
>> IMHO we should rather adopt the coding style of the kernel which rather
>> tries to avoid to typedef each and every struct.
> From 
> https://www.kernel.org/doc/html/latest/process/coding-style.html#typedefs :
> "In general, a pointer, or a struct that has elements that can reasonably be
>  directly accessed should never be a typedef."
> So if we were to adopt the coding style of the kernel, we'd have to face a
> lot more violations with the current QEMU code base :)

Yes, that's just not going to happen.  QEMU has a different coding
style; it's used consistently(*) and we'll live with it. I do like the
kernel style too as well, but it's just too different for a transition
to make sense and it may make even less sense if QEMU ever becomes
multi-language.  To put it clearly, this is not multiline comments.

It's a different thing to allow struct in prototypes, that's a special
case that already exists and can be adopted only if necessary.


    (*) camel-case type identifiers are also shared with GLib and many
        other libraries we use, and they are pretty much a universal
        convention in every language but C and C++.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]