This patch fixes the C++ compilation error:

ISO C++ forbids forward references to 'enum' types

Signed-off-by: Will Hollins <whollins@google.com>
Signed-off-by: Roman Kiryanov <rkir@google.com>
---
 include/ui/kbd-state.h | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/ui/kbd-state.h b/include/ui/kbd-state.h
index 1f37b932eb..3522ebe51b 100644
--- a/include/ui/kbd-state.h
+++ b/include/ui/kbd-state.h
@@ -9,9 +9,7 @@
 
 #include "qapi/qapi-types-ui.h"
 
-typedef enum QKbdModifier QKbdModifier;
-
-enum QKbdModifier {
+typedef enum QKbdModifier {
     QKBD_MOD_NONE = 0,
 
     QKBD_MOD_SHIFT,
@@ -23,7 +21,7 @@ enum QKbdModifier {
     QKBD_MOD_CAPSLOCK,
 
     QKBD_MOD__MAX
-};
+} QKbdModifier;
 
 typedef struct QKbdState QKbdState;
 
-- 
2.53.0.rc1.225.gd81095ad13-goog

Hi,

On 29/1/26 20:04, Roman Kiryanov wrote:
> This patch fixes the C++ compilation error:
> 
> ISO C++ forbids forward references to 'enum' types
> 
> Signed-off-by: Will Hollins <whollins@google.com>
> Signed-off-by: Roman Kiryanov <rkir@google.com>
> ---
>   include/ui/kbd-state.h | 6 ++----
>   1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/include/ui/kbd-state.h b/include/ui/kbd-state.h
> index 1f37b932eb..3522ebe51b 100644
> --- a/include/ui/kbd-state.h
> +++ b/include/ui/kbd-state.h
> @@ -9,9 +9,7 @@
>   
>   #include "qapi/qapi-types-ui.h"
>   
> -typedef enum QKbdModifier QKbdModifier;
> -
> -enum QKbdModifier {
> +typedef enum QKbdModifier {
>       QKBD_MOD_NONE = 0,
>   
>       QKBD_MOD_SHIFT,
> @@ -23,7 +21,7 @@ enum QKbdModifier {
>       QKBD_MOD_CAPSLOCK,
>   
>       QKBD_MOD__MAX
> -};
> +} QKbdModifier;

Yes but:

$ git grep -E 'typedef enum.*;'
hw/core/loader.c:1691:typedef enum HexRecord HexRecord;
hw/display/xlnx_dp.c:259:typedef enum DPGraphicFmt DPGraphicFmt;
hw/display/xlnx_dp.c:260:typedef enum DPVideoFmt DPVideoFmt;
hw/dma/xlnx_dpdma.c:156:typedef enum DPDMABurstType DPDMABurstType;
hw/dma/xlnx_dpdma.c:157:typedef enum DPDMAMode DPDMAMode;
hw/riscv/riscv-iommu.h:28:typedef enum riscv_iommu_igs_modes 
riscv_iommu_igs_mode;
include/hw/misc/auxbus.h:32:typedef enum AUXCommand AUXCommand;
include/hw/misc/auxbus.h:33:typedef enum AUXReply AUXReply;
include/hw/pci/pci_device.h:52:typedef enum PCIReqIDType PCIReqIDType;
include/hw/ssi/ssi.h:19:typedef enum SSICSMode SSICSMode;
include/hw/xen/interface/io/xenbus.h:51:typedef enum xenbus_state 
XenbusState;
include/io/channel.h:41:typedef enum QIOChannelFeature QIOChannelFeature;
include/io/channel.h:54:typedef enum QIOChannelShutdown QIOChannelShutdown;
include/system/replay.h:29:typedef enum ReplayClockKind ReplayClockKind;
include/system/replay.h:44:typedef enum ReplayCheckpoint ReplayCheckpoint;
include/ui/clipboard.h:23:typedef enum QemuClipboardType QemuClipboardType;
include/ui/clipboard.h:24:typedef enum QemuClipboardNotifyType 
QemuClipboardNotifyType;
include/ui/clipboard.h:25:typedef enum QemuClipboardSelection 
QemuClipboardSelection;
include/ui/kbd-state.h:12:typedef enum QKbdModifier QKbdModifier;
pc-bios/s390-ccw/virtio.h:31:typedef enum VirtioDevType VirtioDevType;
pc-bios/s390-ccw/virtio.h:182:typedef enum guessed_disk_nature_type 
VirtioGDN;
qapi/opts-visitor.c:63:typedef enum ListMode ListMode;
qapi/string-output-visitor.c:53:typedef enum ListMode ListMode;
target/s390x/gen-features.c:1175:           "typedef enum {\n");
tests/qtest/libqos/qgraph_internal.h:30:typedef enum QOSEdgeType 
QOSEdgeType;
tests/qtest/libqos/qgraph_internal.h:31:typedef enum QOSNodeType 
QOSNodeType;
tests/unit/check-qom-proplist.c:43:typedef enum DummyAnimal DummyAnimal;

If we want QEMU headers to be C++ compilable, we should
1/ fix all enum forward declarations and
2/ add a CI job to ensure no more are added

Hi Philippe, thank you for looking into my patch.

On Thu, Jan 29, 2026 at 11:23 AM Philippe Mathieu-Daudé
<philmd@linaro.org> wrote:
>
> On 29/1/26 20:04, Roman Kiryanov wrote:
> > This patch fixes the C++ compilation error:
> >
> > ISO C++ forbids forward references to 'enum' types
> >
> > -typedef enum QKbdModifier QKbdModifier;
> > -
> > -enum QKbdModifier {
> > +typedef enum QKbdModifier {
> > -};
> > +} QKbdModifier;
>
> Yes but:
>
> $ git grep -E 'typedef enum.*;'
> include/hw/misc/auxbus.h:32:typedef enum AUXCommand AUXCommand;

I also grepped through the QEMU source code and saw other examples. I
limited this patch to ui/kbd-state.h because it is the specific header
causing C++ compilation errors in our project. I hesitated to touch
the others to keep the diff minimal and avoid changes in files we
aren't currently using.

Currently, QEMU has a mix of incompatible and compatible (e.g.
block/block-common.h, BlockZoneOp) enum definitions. I think,
everything outside the include/ directory should be implementation
details.

How would you prefer I proceed?

1) Keep this patch focused: Limit the change to kbd-state.h to fix the
active build breakage.
2) Fix public headers: I can send a v2 that fixes this pattern for all
files in include/.
3) Tree-wide cleanup: I can attempt to fix every instance found by
grep, though this touches private headers as well.

> 2/ add a CI job to ensure no more are added

Regarding CI: Since our project consumes QEMU headers in a C++
environment, we are effectively serving as a test case for this. We
are happy to continue submitting patches as we encounter these
compatibility issues.

On Thu, 29 Jan 2026 at 20:26, Roman Kiryanov <rkir@google.com> wrote:
>
> Hi Philippe, thank you for looking into my patch.
>
> On Thu, Jan 29, 2026 at 11:23 AM Philippe Mathieu-Daudé
> <philmd@linaro.org> wrote:
> >
> > On 29/1/26 20:04, Roman Kiryanov wrote:
> > > This patch fixes the C++ compilation error:
> > >
> > > ISO C++ forbids forward references to 'enum' types
> > >
> > > -typedef enum QKbdModifier QKbdModifier;
> > > -
> > > -enum QKbdModifier {
> > > +typedef enum QKbdModifier {
> > > -};
> > > +} QKbdModifier;
> >
> > Yes but:
> >
> > $ git grep -E 'typedef enum.*;'
> > include/hw/misc/auxbus.h:32:typedef enum AUXCommand AUXCommand;
>
> I also grepped through the QEMU source code and saw other examples. I
> limited this patch to ui/kbd-state.h because it is the specific header
> causing C++ compilation errors in our project. I hesitated to touch
> the others to keep the diff minimal and avoid changes in files we
> aren't currently using.
>
> Currently, QEMU has a mix of incompatible and compatible (e.g.
> block/block-common.h, BlockZoneOp) enum definitions. I think,
> everything outside the include/ directory should be implementation
> details.
>
> How would you prefer I proceed?
>
> 1) Keep this patch focused: Limit the change to kbd-state.h to fix the
> active build breakage.
> 2) Fix public headers: I can send a v2 that fixes this pattern for all
> files in include/.
> 3) Tree-wide cleanup: I can attempt to fix every instance found by
> grep, though this touches private headers as well.

There is also option 4:

4) Don't change this, because QEMU is not a C++ project
and it's not a goal for our headers to be compilable
with C++, with some minor exceptions.

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.

thanks
-- PMM

Hello Peter, thank you for looking.

On Thu, Jan 29, 2026 at 12:31 PM Peter Maydell <peter.maydell@linaro.org> wrote:
> > How would you prefer I proceed?
> There is also option 4:
>
> 4) Don't change this, because QEMU is not a C++ project
> and it's not a goal for our headers to be compilable
> with C++, with some minor exceptions.
>
> What are we trying to achieve here, and why does it benefit
> us as an upstream project ?

The Goal: to cleanup the specific header include/ui/kbd-state.h by
removing a redundant enum declaration. I realize my original patch
description focused on C++, so I will update the commit message in v2
to reflect this cleanup as the primary goal.

The Benefit to Upstream: Currently, this file uses a verbose style
where a forward declaration immediately precedes the definition.

In this context, the forward declaration is effectively dead code. My
patch consolidates this into the cleaner, standard C idiom found
elsewhere in the tree (e.g. include/block/block-common.h):

We are proposing this change because kbd-state.h is a public interface
header causing friction for downstream C++ consumers. By adopting the
cleaner C idiom here (which benefits QEMU by removing redundancy), we
also resolve that downstream friction as a side effect.

Hi Peter,

(+Paolo / Eric)

On 29/1/26 21:31, Peter Maydell wrote:
> On Thu, 29 Jan 2026 at 20:26, Roman Kiryanov <rkir@google.com> wrote:
>>
>> Hi Philippe, thank you for looking into my patch.
>>
>> On Thu, Jan 29, 2026 at 11:23 AM Philippe Mathieu-Daudé
>> <philmd@linaro.org> wrote:
>>>
>>> On 29/1/26 20:04, Roman Kiryanov wrote:
>>>> This patch fixes the C++ compilation error:
>>>>
>>>> ISO C++ forbids forward references to 'enum' types
>>>>
>>>> -typedef enum QKbdModifier QKbdModifier;
>>>> -
>>>> -enum QKbdModifier {
>>>> +typedef enum QKbdModifier {
>>>> -};
>>>> +} QKbdModifier;
>>>
>>> Yes but:
>>>
>>> $ git grep -E 'typedef enum.*;'
>>> include/hw/misc/auxbus.h:32:typedef enum AUXCommand AUXCommand;
>>
>> I also grepped through the QEMU source code and saw other examples. I
>> limited this patch to ui/kbd-state.h because it is the specific header
>> causing C++ compilation errors in our project. I hesitated to touch
>> the others to keep the diff minimal and avoid changes in files we
>> aren't currently using.
>>
>> Currently, QEMU has a mix of incompatible and compatible (e.g.
>> block/block-common.h, BlockZoneOp) enum definitions. I think,
>> everything outside the include/ directory should be implementation
>> details.
>>
>> How would you prefer I proceed?
>>
>> 1) Keep this patch focused: Limit the change to kbd-state.h to fix the
>> active build breakage.
>> 2) Fix public headers: I can send a v2 that fixes this pattern for all
>> files in include/.
>> 3) Tree-wide cleanup: I can attempt to fix every instance found by
>> grep, though this touches private headers as well.
> 
> There is also option 4:
> 
> 4) Don't change this, because QEMU is not a C++ project
> and it's not a goal for our headers to be compilable
> with C++, with some minor exceptions.
> 
> 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.

See for example non-invasive commit 7246c4cc470 ("exec: don't use void*
in pointer arithmetic in headers"):

-- >8 --
diff --git a/include/exec/memory.h b/include/exec/memory.h
@@ -2767 +2767 @@ struct MemoryRegionCache {
-    void *ptr;
+    uint8_t *ptr;
---

or commit 17c7df806b3 ("exec: avoid using C++ keywords in function
parameters"):

-- >8 --
diff --git a/include/exec/memory.h b/include/exec/memory.h
@@ -928 +928 @@ struct MemoryListener {
-                      int old, int new);
+                      int old_val, int new_val);
@@ -947 +947 @@ struct MemoryListener {
-                     int old, int new);
+                     int old_val, int new_val);
---


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.


On another perspective, having more contributors should keep our project
healthy, and would potentially bring us more reviewers (maintainers?).


If we don't object to take such patches, my only request is to have a
CI job for non-C++ developers to not breaking the headers over time.


My 2 cents :)

Regards,

Phil.

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. 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

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 :|

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é <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.

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/20260130211746.46667-3-philmd@linaro.org/

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

Philippe Mathieu-Daudé <philmd@linaro.org> 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é <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.
>
> 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/20260130211746.46667-3-philmd@linaro.org/

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.

Peter Maydell <peter.maydell@linaro.org> writes:

> 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.

+1

[...]

On Thu, Jan 29, 2026 at 11:06 PM Roman Kiryanov <rkir@google.com> wrote:
>
> This patch fixes the C++ compilation error:
>
> ISO C++ forbids forward references to 'enum' types
>
> Signed-off-by: Will Hollins <whollins@google.com>
> Signed-off-by: Roman Kiryanov <rkir@google.com>

Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>

> ---
>  include/ui/kbd-state.h | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/include/ui/kbd-state.h b/include/ui/kbd-state.h
> index 1f37b932eb..3522ebe51b 100644
> --- a/include/ui/kbd-state.h
> +++ b/include/ui/kbd-state.h
> @@ -9,9 +9,7 @@
>
>  #include "qapi/qapi-types-ui.h"
>
> -typedef enum QKbdModifier QKbdModifier;
> -
> -enum QKbdModifier {
> +typedef enum QKbdModifier {
>      QKBD_MOD_NONE = 0,
>
>      QKBD_MOD_SHIFT,
> @@ -23,7 +21,7 @@ enum QKbdModifier {
>      QKBD_MOD_CAPSLOCK,
>
>      QKBD_MOD__MAX
> -};
> +} QKbdModifier;
>
>  typedef struct QKbdState QKbdState;
>
> --
> 2.53.0.rc1.225.gd81095ad13-goog
>
>


-- 
Marc-André Lureau