C/C++ incompatibilities

[jaykrell]

This is a summary document with the issues we have found during C++ port. We intend to use this as a guidance how to resolve compilation issues if we want to have a common code base which compiles with C and C++ compilers

Every problem has been solved, in at least one way, and all problems have working solutions.
("working" meaning many CI lanes are green, just finishing off Windows.)

Also most these proposals are already in master to some extent (except "autocast" and enum operators), but not every instance of every problem has been fixed yet in master.

The github links often do not work particularly well, jumping to a commit or PR but not landing on the correct lines, without waiting and/or scrolling around.

void*-vs-non-void*-function-return [voidp-ret]

This is far and away our biggest problem. While the obvious fix is very safe and mechanical and locally small, and everyone understands it, and it obviously preserves semantics, it is the largest due to number of occurrences.

C allows the following:

void* get_foo();
int *a = get_foo();

gcc allows it with -fpermissive but msvc and clang do not.

Proposals

Insert casts as needed [voidp-ret-cast]

This is very simple, works, no #ifdef __cplusplus, very voluminous.

int *a = (int*)get_foo();

e.g.
#10045
67906d3#diff-34d834b8d69724f49f21964be1e1258dL85

This seems like the most obvious choice, but there are others.

An example of a PR "with all the casts", without "auto cast" is:
https://github.com/mono/mono/pull/9950/files
"auto cast" does not reduce this to zero, but it does reduce it a lot.

Resolution

TBD

[voidp-ret-autocast]

In many cases, not all, a trick:

#ifdef __cplusplus
struct g_cast { .. something-not-hypothetical .. };
#else
#define g_cast(x) x
#endif

#define get_foo() (g_cast (get_foo())

This works with g_malloc, g_malloc0, and many others, but not all.
It does cut down the line damage from other choices.
It would have to be combined with another option.

https://github.com/mono/mono/pull/10027/files#diff-b8c6c2ba344450884373fb00f33685adR57
+
https://github.com/mono/mono/pull/10027/files#diff-b8c6c2ba344450884373fb00f33685adR1272

Still leaving all these casts:
#10036

Change output signature [voidp-ret-voidpp]

int* a;
get_foo((void**)&a);

No examples written but obvious.
Disadvantage: Prefer not to change C signatures.

Sometimes change output signature [voidp-ret-strengthen]

#10042

This is probably how those specific functions should be, but does not apply broadly.

Change g_malloc to g_new [voidp-ret-gnew]

It works, but does not apply broadly due to "array at end" and "other allocators".

Templatize [voidp-ret-templatize]

This is probably outside scope at this time.

Resolution

TBD

void*-vs-non-void* in function parameters values [voidp-param]

For example:

void mono_gc_wbarrier_generic_store (..., MonoObject*);
gpointer value;
mono_gc_wbarrier_generic_store (value_addr, value); // error: value must be MonoObject*

Proposals

[voidp-param-cast]

mono_gc_wbarrier_generic_store (value_addr, (MonoObject*)value);

weaken parameter type [voidp-param-weaken]

void mono_gc_wbarrier_generic_store (..., gpointer);
gpointer value;
mono_gc_wbarrier_generic_store (value_addr, value);

If something is "weakly typed" make it a gpointer/void*, not a char* or guint8*:

#9881

"Weakly typed" isn't well defined.
Arguably guint8* is a strong type -- "array of bytes".
Arguably MonoObject* is a strong type.
It seems a little unfair to declare the root of a type hierarchy as weak, in the face of multiple such hierarchies.

Disadvantage: Probably better to leave C signatures all alone. Therefore, cast.

Resolution

TBD

void*-vs-non-void* in struct fields [voidp-vs-void-struct-field]

Proposals

Change struct fields from gpointer

For example:
#9888

Cast more

Note that struct that are not declared, are still opaque.
#9761

is a good change. It helps debugging and maintainability. Or cast more.

Resolution

TBD

Function pointers do not silently convert to void* in C++ [functionp-to-voidp-output]

For example, as function return values.

Occasionally strengthen type:

#10057

when they are of the same type.

Usually cast:
37c7d3a

Sometimes via a macro:
https://github.com/mono/mono/pull/10036/files#diff-51871b3c9f77c36adec88b19019cb69aR560

gpointer get_foo()
{
#define return return (gpointer)
 if (..) return f1;
 else if (..) return f2;
 else if (..) return f3;
#undef return
}

The macros seems a little sleazy, but sometimes it is quite a few lines.

This found a bug (that I wrote, oops):
#10117

Resolution

TBD

Function pointers do not silently convert to void* in C++ [functionp-to-voidp-input]

For example, as function parameters.

void register_jit_icall (gpointer);

void f1();

void f2()
{
	register_jit_icall(f1); // error
}

Occasionally strengthen type:

Thread creation could be fixed here.

Cast, or a macro:

#9992

#define foo(x, y) (foo((gpointer)(x), (y))

Example:
https://github.com/mono/mono/pull/10036/files#diff-b00b862030776d18eacb5c73934413a8R53
https://github.com/mono/mono/pull/9764/files#diff-d3ba4b3a1317ed875ae9f7f56ce199b8R2050

Resolution

TBD

Enum vs. int [enum-vs-int]

Enums cannot be assigned from integers and don't allow for math, or somesuch.

typedef enum Color { red, blue } Color;

Color r = 0;
Color purple = red + blue;
Color b = r + 1;

Proposals

Insert casts [enum-vs-int-cast]

67906d3#diff-de21c55465380611eb87eed09b51e13eR18

67906d3#diff-e7e458b6256eaa730c145f14a666652aR776

Generate operator overloads [enum-vs-int-operator-overload]

https://github.com/mono/mono/pull/10027/files#diff-b8c6c2ba344450884373fb00f33685adR92
Seems strange, but is idiomiatic. Windows.h offers this.
Limits line damage.

Use ints instead, as that is what C enums are.

This is kinda an obvious safe change, but debugging suffers.
Debugging suffers because debuggers can show enums by their names or even as bitwise-or of names, as long as a variable is actually typed with a typedef.
The retyping of a enum as int could be C++ specific to limit the debugging damage.

[enum-vs-int-just-int-always]

enum { red, blue };
typedef int Color;

[enum-vs-int-just-int-cxx]

enum Color { red, blue };
#ifdef __cplusplus
typedef int Color;
#else
typedef enum Color Color;
#endif

Resolution

TBD

Goto-around-init

C++ does not allow:

int f1();

int f2()
{
  if (f1())
     goto exit; // error: goto around init of i
  int i = f1();
exit:
  return 0;
}

Even though i is not used after exit:.

Proposals

Split decl from init [goto-around-init-split-decl-from-init]

int f2()
{
  if (f1())
    goto exit;
  int i;
  i = f1();
exit:
  return 0;
}

#10132
#9785

Jump up [goto-around-init-goto-up]

int f2()
{
  if (0) {
exit:
    return 0;
  }
  if (f1())
    goto exit;
  int i = f1();
  goto exit;
}

Second is less damage, sometimes -- there needs to be multiple goto to be worthwhile, and have to move the end of the function.

https://github.com/mono/mono/pull/9764/files#diff-9df70935849c9fb54aea9bff7a39533fR1170

Resolution

TBD

Where to put extern "C"?

Proposals

Everywhere

Only where needed

Very initial work put extern "C" around every header (but not #include -- each header owns its own content.)
This allowed a gradual port -- mini, metadata, utils, sgen.
As the port progressed, the need to support a mixed tree both fell away, and in future could become detrimental. In particular, you cannot have extern "C" overloads or templates -- though you can selectively wrap in extern "C++" to nest those within an otherwise extern "C" context.

As well, I later had the epiphany to build extern "C" into MONO_API and ICALL_EXPORT.
That is in master.

Still later (8/14/2018) as most platforms are passing in CI, I come to WebAssembly. I have not fully discovered all of its "bindings" and as such have sprinkled some additional extern "C" around to make it pass.

If mechanisms such as name-overloading and templates become banned by future policy, then extern "C" around .h and even .c becomes a significant enforcement of that policy.

#10141
#9814

Resolution

TBD

Designated initializers

C++ has no designated initializers.

Current clang, no problem.
Current gcc, some problems.
Centos6/gcc4.4: no support
msvc?

Proposals

There are two kinda disjoint cases here -- locals and globals.
They could be merged, but the tradeoffs are kinda opposite.

locals: memset

memset them and fill in each field by name (or index, hypothetically).
Locals could also be handled like globals, but it is extra unneeded verification on the ordering.

5157357#diff-40253f389761b6525e7f5594c2d94debR1840

globals: ensure correct order.

have the initializer match up with the field order.
They all do already from what I've seen.

include+define: must line up in order

Mostly already fixed in master:
5157357

Residual either I missed or new since then:
#10109

Resolution

TBD

'a': int vs. char [char-literal-is-char-or-int]

In C, the type of 'a' is int (sizeof('a')==4). In C++ it is char (sizeof('a')==1)
This is a semantic difference and a slight risk.

Indexing an array with a character constant, as mono does, gets a warning. Cast to int.

#10118

Resolution

TBD

Keywords

Mono has identifiers like new, class, namespace, typename.
Rename to new_, klass, name_space, type_name, etc.
(C++ has other new keywords: template, operator, etc.)

801e3f3

Resolution

TBD

Complex/imaginary numbers

Mono uses complex/imaginary math, that was not valid C++.
While C++ has an ancient, small, inlinable complex number library, libstdc++/libc++ dependency is to be avoided at this stage, inlining is not guaranteed, so this has been ported to just use double.

3695672

Resolution

TBD

C++11 user defined literals "foo"bar

In C++11 you can have "user defined literals" which are strings appended with a type-specific user-provided suffix. For example..and I don't exact the syntax, I have never done this but something like:

class distance { distance(inches); distance(feet);. };
class time { time(seconds); time(milliseconds); }

time five_seconds = "5"s;
time half_second = "500"ms;
distance football_field = "300"ft; // or "100"yd
distance just_made_it_by_a_few = "3"inch;

This is ambiguous with C++98 and C such as:

#include <inttypes.h>
#define PRI32 "%d"

int32_t i;
printf("i is "PRI32"\n", i);

And an error.
To fix, just put spaces before/after quotes:
printf("i is " PRI32 "\n", i);

After suffices, before/after is clearer.

9bafdc2

Resolution

TBD

WebAssembly requires types be unique.

https://jenkins.mono-project.com/job/test-mono-pull-request-wasm/3652/parsed_console/log.html

invalid enum type
!19255 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !7355, producer: "clang version 5.0.0 (emscripten 1.37.36 : 1.37.36)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !19256, retainedTypes: !19257, imports: !19263)
!19256 = !{!7363, !6973, !168}
!7363 = distinct !DICompositeType(tag: DW_TAG_structure_type, file: !7364, line: 192, size: 128, elements: !7365, identifier: "_ZTS10ParseState")
/mnt/jenkins/workspace/test-mono-pull-request-wasm/sdks/builds/toolchains/emsdk/clang/e1.37.36_64bit/llvm-link: error: linked module is broken!

Rename to make them so, or use #define.

#10091

Resolution

TBD

wchar and unsigned short are different types [wchart-is-not-ushort]

Mono does this on Windows:

typedef unsigned short gunichar2;
gunichar2* foo;
wcslen(foo);

This is incorrect and generates warnings or errors. wchar_t is not unsigned short. It is a unique type.
Fix is to use whatever the platform defines:

#10056
#10112

C++ rationale: This is because you can overload.
unsigned short is a "small number".
wchar_t is a "wide character".
"characters" and "numbers" are different.

print(wchar_t);
print(unsigned short);
print(L'a') // "a"
print((unsigned short)65) // "65"

Resolution

TBD

Misalligned if-defs

C++ compiler finds random mistakes.
For example, in sgen we have:

#if defined (HOST_WIN32)
...
#elif defined (HAVE_UNISTD_H)
...
#endif

followed by the opposite:

#if defined (HAVE_UNISTD_H)
...
#elif defined (HOST_WIN32)
...
#endif

But the defines are not mutually exclusive. The two chunks are meant to match up.
The fix is to have a consistent order, or maybe something else, since that is still error-prone.

#10077

Resolution

TBD

Incorrect Prototypes

Some functions have deliberately incorrect prototypes.
This is anything involving THREAD_INFO_TYPE and MonoGCDescriptor (mono_gc_alloc_fixed).
These are hacks and they lead to C++ link failures.

Proposals

Sprinkle extern "C" around more.

Typesafe wrappers or overloads.

https://github.com/mono/mono/pull/10087/files#diff-bd3a3d5c2bfd6af46373b3844de9c1d0R444
https://github.com/mono/mono/pull/10087/files#diff-bd3a3d5c2bfd6af46373b3844de9c1d0R163

#10297
#10294
#10293

Resolution

TBD

Copied instead of shared enums

Mono duplicates enums that are meant to be the same.
Either share the types as intended, or cast more.

#6700
or
https://github.com/mono/mono/pull/10087/files#diff-d5708d26cfbc2037ac98c34b2e708387R1807

Resolution

TBD

Incorrect Code

The C++ compiler rejects obviously incorrect code that the C compiler accepts.

#10117

Resolution

Fix the code

How much to port?

glib, utils, metadata, sgen, mini, pedump, monodis, monograph, unit-tests, "main", ios, Android, Mac, Linux, WebAssembly, Windows, arm, arm64, amd64, x86 all building and passing in CI (branch configure.ac hacked to always be C++). All fixes are in master or will be shortly.

Windows MSBuild project files were successfully prototyped (/TP) and Visual C++-specific problems fixed.

The more that is ported, the less extern "C" is needed.
libtest, profiler, and MonoPosixHelper were ported, easily, but extern "C" added to workaround instead.

[marek-safar]

/cc @migueldeicaza

[jaykrell]

[libc-overload-address-taken-ambiguous]

C++ standard library overloads functions.
Taking the address of them, which Mono does, once, is ambiguous and an error.

$ cat 1.cpp
#include <math.h>
void* pfmod = (void*)&fmod;

$ cc -c 1.cpp

1.cpp:2:17: error: address of overloaded function 'fmod' does not match required type 'void'
void* pfmod = (void*)&fmod;

Solution 1: Use the correct type when taking the address.

$ cat 2.cpp
#include <math.h>
typedef double (*fmod_t)(double, double);
fmod_t pfmod = fmod;

$ cc -c 2.cpp
<success>

1cd0294
#10147

Solution 2:

Compile some of the runtime as C.
This devolves in general to all standard library interactions
going through an intermediate small mono C library -- mono_fmod etc.

As there is only one occurence of this, it is not controversial and just take option 1.
Option 2 remains available, however, with nearly everything working, the need has not arisen.

Solution 3

An intermediate function, but still C++, would also work:

#include <math.h>

double mono_fmod (double a, double b)
{
	return fmod (a, b);
}

void * pfmod1 = (void*)mono_fmod;
auto const pfmod2 = mono_fmod;

[libc-noexcept]

C++11 standard library offers noexcept() semantics, which implies a runtime dependency.

$ make

  CCLD     mono-boehm
Undefined symbols for architecture x86_64:
  "std::terminate()", referenced from:
      ___clang_call_terminate in libmini.a(libmini_la-jit-icalls.o)
      ___clang_call_terminate in libmini.a(libmini_la-mini-amd64.o)
      ___clang_call_terminate in libmono-ee-interp.a(libmono_ee_interp_la-interp.o)
      ___clang_call_terminate in libmonoruntime.a(libmonoruntime_la-sysmath.o)
  "___cxa_begin_catch", referenced from:
      ___clang_call_terminate in libmini.a(libmini_la-jit-icalls.o)
      ___clang_call_terminate in libmini.a(libmini_la-mini-amd64.o)
      ___clang_call_terminate in libmono-ee-interp.a(libmono_ee_interp_la-interp.o)
      ___clang_call_terminate in libmonoruntime.a(libmonoruntime_la-sysmath.o)

$ cc -xc++  mono/metadata/sysmath.c -I. -Imono/eglib -I./mono -std=c++11 
Undefined symbols for architecture x86_64:
  "std::terminate()", referenced from:
      ___clang_call_terminate in sysmath-e893eb.o
  "___cxa_begin_catch", referenced from:
      ___clang_call_terminate in sysmath-e893eb.o

$ cat 3.cpp

#include <math.h>

double x;

int main()
{
	return isnan(x);
}

$ cc -std=c++11 3.cpp

Undefined symbols for architecture x86_64:
  "std::terminate()", referenced from:
      ___clang_call_terminate in 3-61530e.o
  "___cxa_begin_catch", referenced from:
      ___clang_call_terminate in 3-61530e.o

Solutions:

1. Use C++98.

$ cc -std=c++98 3.cpp

2. Compile some runtime as C (like unused solution 2 to [libc-overload-address-taken-ambiguous]).

3. Accept dependency, at least on desktop.

$ c++ -std=c++11 3.cpp
$ nm a.out
                 U __ZSt9terminatev
0000000100000f70 t ___clang_call_terminate
                 U ___cxa_begin_catch

4. Hack around it in platform-specific way.

ac3bd39

$ cat 4.cpp
// First run through __config to get an initial _NOEXCEPT.
#include <stddef.h>
// Then replace it with empty.
#undef _NOEXCEPT
#define _NOEXCEPT
// Then get the declarations from math.h we use that would have _NOEXCEPT.

#include <math.h>

double x;

int main()
{
	return isnan(x);
}

$ cc -std=c++11 4.cpp

5. Compile with -fno-exceptions.

$ cc -fno-exceptions -xc++ -std=c++11 3.cpp

Solution 5 at least.
The others remain available if needed. Not likely.

It was only in adding to this github issue that I realized -fno-exceptions was offering a workaround, and therefore ac3bd39
can be stricken.

[extern-const-vs-static-const]

In C:

const int foo = 1;

is equivalent to:

extern const int foo = 1;

In C++ it is equivalent to:

static const int foo = 1;

This is the most well known semantic difference between C and C++.

I did not notice it in mono at all.

There are some workarounds.

The most obvious is, never write const int foo = 1;
Always write extern const int foo = 1;
or static const int foo = 1;

These are both valid C and C++ and have the same meaning in both.

gcc warns for extern const int foo = 1, so the workaround I used for years is:

// Workaround gcc warning.
#ifdef __cplusplus
#define EXTERN_CONST extern const
#else
#define EXTERN_CONST const
#endif

However upon complaining to the gcc developers:
https://gcc.gnu.org/ml/gcc/2018-01/msg00144.html

They suggested declare first for extern:

extern const int foo;
const int foo = 1;

Anyway, this does not occur in mono.

[constants-must-be-initialized]

This occurs once in Mono and is trivially worked around.

$ cat 5.c 
const int i;
const struct { int a,b,c; } d;
$ cc -c 5.c
$ cc -c -xc++ 5.c

5.c:1:11: error: default initialization of an object of const type 'const int'
const int i;
          ^
            = 0
5.c:2:29: error: default initialization of an object of const type 'const struct (anonymous struct at 5.c:2:7)' without a user-provided default constructor
const struct { int a,b,c; } d;
                            ^
                              = {}
2 errors generated.

$ cat 6.c
const int i = 0; // { 0 } works generically
const struct { int a,b,c; } d = { 0 };
$ cc -c 6.c
$ cc -c -xc++ 6.c

907c887
#10146

[const]

C++ is pickier about const, including on string literals, and providing const-sensitive overloads in the standard library.
Add or remove const, or cast, to workaround.

ccf1943

$ cat const-broken.cpp 
#include <string.h>

char * a = strchr("", 0);

char *b [] = {""};

$ cc -c const-broken.cpp 
const-broken.cpp:3:8: error: cannot initialize a variable of type 'char *' with an rvalue of type 'const char *'
char * a = strchr("", 0);
       ^   ~~~~~~~~~~~~~
const-broken.cpp:5:15: warning: conversion from string literal to 'char *' is deprecated [-Wc++11-compat-deprecated-writable-strings]
char *b [] = {""};
              ^
1 warning and 1 error generated.

$ cat const-fixed-1.cpp
#include <string.h>

const char * a = strchr("", 0);

const char *b [] = {""};

$ cat const-fixed-2.cpp
#include <string.h>

char * a = (char*)strchr("", 0);

char *b [] = {(char*)""};
$ cc -c const-fixed-1.cpp const-fixed-2.cpp 

[pointer-truncation]

C++ is less willing to let you truncate pointers.

$ cat int-pointer-size-mismatch.cpp
void f(void)
{
	int a = (int)&a;
}

$ cc -xc -c int-pointer-size-mismatch.cpp 

$ cc -xc++ -c int-pointer-size-mismatch.cpp 
int-pointer-size-mismatch.cpp:3:10: error: cast from pointer to smaller type 'int' loses information
        int a = (int)&a;
                ^~~~~~~
1 error generated.

$ cat int-pointer-size-mismatch-fixed.cpp
#include <stddef.h>
void f(void)
{
	int a = (int)(size_t)&a;
}

$ cc -xc -c int-pointer-size-mismatch-fixed.cpp 
$ cc -xc++ -c int-pointer-size-mismatch-fixed.cpp 

If the intent is really to truncate, cast, or use a helper function.

7c245d7#diff-e024ef331fa80ca76a1bcfcb3f2950bfL337

[integer-truncation]

g++ is less willing to let you truncate integer constants than gcc. clang doesn't care.
Change the type if the semantics are ok, or cast to preserve semantics, or turn off the warning.

$ cat truncate.cpp
const struct { int a; } b = { 0x80000000 };

$ cc -xc -c truncate.cpp
$ cc -xc++ -c truncate.cpp
truncate.cpp:1:42: error: narrowing conversion of ‘2147483648’ from ‘unsigned int’ to ‘int’ inside { } [-Wnarrowing]
 const struct { int a; } b = { 0x80000000 };
                                          ^
$ cat truncate-cast.cpp 
const struct { int a; } b = { (int)0x80000000 };
$ cc -xc -c truncate-cast.cpp
$ cc -xc++ -c truncate-cast.cpp

$ cat truncate-unsigned.cpp 
const struct { unsigned a; } b = { 0x80000000 };

$ cc -xc -c truncate-unsigned.cpp 
$ cc -xc++ -c truncate-unsigned.cpp 

4e339c3
#10053

[build]

1. To avoid renaming files, in the near or long term, gcc/clang -xc++ and cl.exe /TP are useful.
   I am using -xc++ but haven't yet altered the .sln/.proj files to use /TP.

2. With clang/gcc, some switches are C-specific and cause warnings or errors when used with -xc++.
   So remove them.

3. Using gcc/clang as the compiler driver along with -xc++ treats binary .a files as C++ source.

clang -xc++ -c 1.cpp 2.cpp
clang -xc++ main.c 1.o 2.o
1.o:1:1: error: source file is not valid UTF-8

clang -xc++ main.c libfoo.a

=> error
This is not yet resolved, except to leave main as C, which really might be ok.

cc -c -xc++ lib1.c
cc -c -xc++ lib2.c
cc main.c lib1.o lib2.o # main is C not C++

If/as the desire for main to be C++ grows, either

1. Rename to main.cpp.
2. Drain main.c into maincpp.cpp leaving main.c just be one line.
3. Other?

More?

Anything else I missed?
One source is the original work in February 2018.
https://github.com/mono/mono/pull/6695/commits

[jaykrell]

[empty-struct-test]

This is not a change in runtime compilation or semantic.
It is only a change in a test semantic (it compiles either way).

libtest.c contains tests that pass around empty structs.

Empty structs are not allowed in ANSI C.

typedef struct A { } A;

cl /c 4.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24234.1 for x64

4.c
4.c(1): error C2016: C requires that a struct or union has at least one member

They are an extension in gcc/clang and have size==0:

typedef struct A { } A;

#include <stdio.h>

int main()
{
 printf("%d\n", (int)sizeof(A));
 return 0;
}

$ cc 1.c -Wall -ansi -pedantic && ./a.out
1.c:1:16: warning: struct has no members [-Wpedantic]
 typedef struct A { } A;
                ^
0

They are valid in C++ and have size==1:

$ cc -xc++ 1.c -Wall -ansi -pedantic && ./a.out
1

This difference in size, means libtest.c has different meaning in C and C++.
If libtest is left as C, that causes the runtime to need more externC,
which I think we are minimizing.
Maybe just one.

If libtest is compiled as C++, the test changes meaning and fails.
The runtime behavior is unchanged. The runtime being portable C that
compiles with msvc, cannot use empty structs, except in gcc/clang-specific paths.

The test is meant to represent user code -- non-standard C code that is not
portable to Windows.

Split up libtest -- part should remain in C.
31ee43b

[jaykrell]

[type-underlying-enum]

I haven't seen this problem, and it difficult to have in code that is portable to multiple platforms/compilers, but clang/gcc and clang++/g++ sometimes differ in choice of type underlying enums.

typedef enum A { zero } A; // clang/gcc unsigned, clang++/g++ int
printf("%d\n", ((A)-1) < 0); // clang/gcc 0, clang++/g++ 1

Visual C++ does not have this problem -- they are both int in C and C++.
In C++11 we can explicitly chose the type underlying enums so if there were an actual problem we would do that.

[jaykrell]

This is essentially all fixed in master now.

Maybe more extern "C" is needed. I think we can resolve and close.

Unless we are keeping notes for further refinement or some additional large scale C to C++ conversion with additional issues -- unlikely.

[jaykrell]

All the C source in sgen/mini/metadata/utils/glib is fixed in master now, for Linux, Mac, Windows, Android, iOS, x86, amd64, arm, arm64. PowerPC, MIPS, SPARC, s390x were mostly ignored, and at least PowerPC and s390x should be dealt with later.

The Windows project files are lagging but there is a working PR (#10442)

I'd say this phase is resolved and next phases are, something like, with consenus:

• test on device and in emulator
• test debugging
• maybe test VS4Mac
• maybe test Unity
• more complete CI to keep it working
  • Such as nightly full run and maybe one optional or required PR lane like Linux/amd64 (certainly not ARM or Mac, in short supply, only Azure).

[luhenry]

Once we know if we want to go for C++ or no, we have to fix the hacks.

[lambdageek]

PR lane is pretty important since we want to guard against regressions