On 31/07/19 08:37, Markus Armbruster wrote: > Paolo Bonzini <pbonz...@redhat.com> writes: > >> On 30/07/19 15:15, Eric Blake wrote: >>>> We occasionally give up and use types directly rather than their typedef >>>> names, flouting the coding style. This patch does. Trades messing with >>>> qemu/typedefs.h for having to write 'struct' a few times. >> >> I think Markus made the right call here. Using "struct Foo;" in headers >> is a null price to pay if all you need is declaring a pointer-typed >> field or parameter. > > Eduardo posted a patch to HACKING to clarify this non-usage of typedef > is okay. > > Should we continue to mandate typedef names elsewhere? It adds > cognitive load: you have to decide where to put the typedef, and when > not to use it.
A lot of libraries we use (especially GLib) use typedefs, so I'd rather keep them. Also, a mass replacement would be tens of thousands of changed lines and not really practical. >> Of course this doesn't apply if you have to embed a >> struct directly, but then qemu/typedefs.h wouldn't help either. > > Yes, and if this leads to an inclusion cycle, I strongly suspect "fat" > headers: since you can't embed something in itself, the cycle must > involve different things, all bunched together in the same header. > >> In general unless you're adding a new subsystem, qemu/typedefs.h should >> only decrease in size, never increase. > > This series grows it some. I'll try to avoid that for v2. Let me review it first. :) Maybe some of them are good to keep. Paolo
