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.
Paolo
(*) 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++.
