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. > 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. > (And there are certainly many > cases where typedefs.h are not needed, but cleaning that up is > understandably not high on the todo list). On the other hand, low-hanging fruit.
