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]/
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
