HL/C compilation fails with C compilers when Haxe field name matches C #define

[joshtynjala]

Similar to the issue with C keywords in #11378, there are other Haxe field names that can cause compilation failure with C compilers when targeting HashLink/C.

In OpenFL's Haxe codebase, I discovered the following field names may conflict with C #define macros, depending on which C compiler and operating system you are building on.

On macOS, I had trouble with compiling with gcc because of these C #defines:

BIG_ENDIAN
LITTLE_ENDIAN

On Windows, I had trouble compiling with Visual Studio because of these C #defines:

ALTERNATE
DIFFERENCE
DOUBLE_CLICK
ERROR
OUT
WAIT_FAILED

I don't have the same issue with hxcpp. However, I discovered that hxcpp uses #undefine for many of the same identifiers (plus some others) here:

https://github.com/HaxeFoundation/hxcpp/blob/master/include/hx/Undefine.h

As a (hopefully temporary) workaround, I am injecting my own #undef directives into the ApplicationMain.c file generated by the Haxe compiler:

#include <hlc_main.c>
// I can manually add #undefs here
#ifndef HL_MAKE

However, it would be nicer if these identifiers were renamed by the Haxe compiler automatically, similar to how you do the same with keywords in the solution to #11378.

[Apprentice-Alchemist]

...at this point I feel like the only reliable solution would be to prefix every haxe generated identifier with _hx_.

Even if we follow every single rule about reserved identifiers in the standard, there is no way for the compiler to know what macros or non-standard keywords might be defined by the specific C compiler used by the end-user.
Or what defines are defined in the headers included by hl.h.

(I mean, I suppose we could somehow make the Haxe compiler aware of the C compiler, somehow detect defined defines, and consider anything other than MSVC, GCC and Clang unsupported, but that seems like a very cursed solution)

---

But for now just adding those defines to the list of reserved identifiers should be good enough.

[kLabz]

How does hxcpp deal with that?

[Simn]

It prefixes every haxe generated identifier with _hx_. And IMO Hashlink should do that as well.

Correction: It prefixes reserved identifiers with that.

[kLabz]

It does seem to have special handling for BIG_ENDIAN, LITTLE_ENDIAN too as well as those listed in that Undefine.h file

https://github.com/HaxeFoundation/hxcpp/blob/18f87b949464ddcf24c6a83a2f7b8f76233540bc/include/hxcpp.h#L122