Philippe Mathieu-Daudé <[email protected]> writes: > On 2/2/26 12:00, Daniel P. Berrangé wrote: >> 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. > > Per the ISO C standard, maybe we should considerate following the same > structure style for enum typedefs was a mistake, and update our coding > style. This is what I suggested here: > > https://lore.kernel.org/qemu-devel/[email protected]/
Is ISO C conformance really a compelling argument? We are relying on multiple Gcc / Clang C extensions. Forward-declared enums is just one of them. >> 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. I think the current code is just fine. >> 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++. Their funeral. Can't see why we'd be interested in enabling it, though.
