[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
Re: [Qemu-ppc] [PATCH v4 2/3] ppc: Drop duplicated typedefs to be able to compile with Clang in gnu99 mode
Thu, 10 Jan 2019 21:35:14 +0100
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
>> only. (Otherwise, all the forward struct definitions at the beginning of
>> spapr.h are a plain violation of the coding style, too...)
>> IMHO we should rather adopt the coding style of the kernel which rather
>> tries to avoid to typedef each and every struct.
> 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++.
[Qemu-ppc] [PATCH v4 3/3] configure: Force the C standard to gnu99, Thomas Huth, 2019/01/10