On Fri, Jan 30, 2026 at 09:19:32AM +0000, Peter Maydell wrote: > On Thu, 29 Jan 2026 at 21:44, Philippe Mathieu-Daudé <[email protected]> > wrote: > > > > Hi Peter, > > > > (+Paolo / Eric) > > > > On 29/1/26 21:31, Peter Maydell wrote: > > > > > > What are we trying to achieve here, and why does it benefit > > > us as an upstream project ? > > > > > > cf previous email thread from 2024 > > > https://lore.kernel.org/qemu-devel/[email protected]/ > > > about "drip-feeding" of this kind of patch with no clear take > > > on what the end state is or how much churn it's going to induce. > > > > I clearly know QEMU is not a C++ project. Now I don't see why we should > > be reluctant to have headers being usable by a C++ compiler, as long as > > it doesn't make our project worst to maintain. > > Every bit of code that is written by some downstream in C++ is > some thing that will essentially then never be upstreamed without > a big rewrite. So making it easier for downstreams to use C++ > reduces our chances of seeing them contribute what they do back to us. > > It's also extra work for us (for instance in this thread you > proposed adding a CI job, which is more CI minutes cost to > the project, more work for maintainers when something that > builds fine locally falls over in the CI, and so on). > > Each individual fix might be trivial, but they add up. > So it matters whether this one is "this is the only thing > we tripped over since 2024" or "we just rebased to a new > QEMU version and are going to be submitting dozens of these > over the next few weeks". > > > See for example non-invasive commit 7246c4cc470 ("exec: don't use void* > > in pointer arithmetic in headers"): > > > or commit 17c7df806b3 ("exec: avoid using C++ keywords in function > > parameters"): > > For the record, I wasn't really enthusiastic about those changes > either, for essentially the same reasons. > > > In this particular case, I always have been confused about what would be > > the size of forward-declared enums. The C99 standard chapter §6.7.2.2 > > point 4 mentions: > > > > Each enumerated type shall be compatible with char, a signed > > integer type, or an unsigned integer type. The choice of type > > is implementation-defined, but shall be capable of representing > > the values of all the members of the enumeration. > > > > When compiling this file with -Werror=pedantic we get: > > > > In file included from ../../ui/kbd-state.c:10: > > include/ui/kbd-state.h:12:14: error: ISO C forbids forward references to > > 'enum' types [-Werror,-Wpedantic] > > 12 | typedef enum QKbdModifier QKbdModifier; > > | ^ > > > > So arguably this could be fixed for C. > > Yes, I actually like the specific change in the patch > on style grounds.
The *current* code style, however, matches the style we use for the struct declaration & typedefs, and it is natural to be consistent in this way. Even within this one file we have this example: typedef enum QKbdModifier QKbdModifier; typedef struct QKbdState QKbdState; And so personally I think the current code is preferrable to this patch. IMHO, if downstream users/developers of a fork really strongly don't want to be writing new devices in C, then the focus should be on Rust as the next generation language, not the C++. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
