Re: [PATCH] ui/kbd-state.h: Make the header C++ compatible

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Jan 30, 2026 at 09:19:32AM +0000, Peter Maydell wrote:
> On Thu, 29 Jan 2026 at 21:44, Philippe Mathieu-Daudé <philmd@linaro.org> 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/ZnqPpqfBxlk9tEdX@redhat.com/
> > > 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 :|