[PATCH 0/1] MR8089: include: Add missing extern "C++" to guiddef.h

[PATCH 1/1] include: Add missing extern "C++" to guiddef.h

[Alfred Agrell]

From: Alfred Agrell

---
 include/guiddef.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/guiddef.h b/include/guiddef.h
index d447388aae5..5673337e397 100644
--- a/include/guiddef.h
+++ b/include/guiddef.h
@@ -174,6 +174,7 @@ inline int InlineIsEqualGUID(REFGUID rguid1, REFGUID rguid2)

#ifdef __cplusplus
 #include <string.h>
+extern "C++" {
 inline bool operator==(const GUID& guidOne, const GUID& guidOther)
 {
     return !memcmp(&guidOne,&guidOther,sizeof(GUID));
@@ -182,6 +183,7 @@ inline bool operator!=(const GUID& guidOne, const GUID& guidOther)
 {
     return !(guidOne == guidOther);
 }
+}
 #endif

#endif /* _GUIDDEF_H_ */

[Alexandre Julliard (＠julliard)]

The PSDK header doesn't have this, why do you need it?

[Alfred Agrell (＠Alcaro)]

- C++-only symbols (potentially) in extern "C" look wrong
- They trigger Clang bugs https://github.com/llvm/llvm-project/issues/140654 (though the actual impact is just about zero, the symbol is marked inline and will be duplicated)
- It will cause errors if any other header defines a different operator== in extern "C"
- It looks weird in debuggers (for example if you tab complete the symbol list), asm output, and similar

But I'm not aware of any real-life application that actually breaks from this. If you feel that behavioral similarity (even with things that look like like upstream bugs) is more important than the above, then feel free to discard it. My programmer instincts keep making me forget Wine's bug compat constraints and general cautiousness.