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. I'm just not a fan of "we should make
our headers compile with some other programming language
that we don't use". C++ should have a better foreign
function interface for consuming C headers that doesn't
mandate changes to the headers it imports :-)
thanks
-- PMM
