HAL headers are not C compatible

[XavilPergis]

Hello, I am writing bindings for the HAL in Rust, and using rust-bindgen to generate the raw wrappers over the HAL headers.

The problem I'm having is that the headers have C++ specific code that is not behind an #ifdef __cplusplus guard, so I need to patch the headers before I can run bindgen on them.

Some of the problems are:

• types on enums (aka enum foo : int32_t {} needs to be enum foo {})
• namespaces
• missing struct/enum keyword (aka HAL_GetJoystickAxes(int32_t joystickNum, HAL_JoystickAxes* axes) needs to be HAL_GetJoystickAxes(int32_t joystickNum, struct HAL_JoystickAxes* axes))
• include of stddef

This change would not break any C++ code.

[ThadHouse]

We had originally started making these entirely C based, but then backed off in the middle to clean up the headers. We had figured most people wouldn't be directly compiling the headers with a C compiler, but would just be using language interop to hook into the C symbols. If you are willing to submit a PR to fix these issues we would look at this. Or we can see if someone can get to this over the summer, but it is unlikely anyone on the WPILib team will be able to do this during the season.

Most of it should just be adding the C++ guards however, which shouldn't be too bad. The only thing we are going to want special is the types on the enums should be ifdef'd out, and not just removed. There are reasons to force that for interop purposes.

[nightpool]

@XavilPergis my understanding is that bindgen supports C++ code. What's the problem with running bindgen in c++ mode? Do you get errors?

[JaciBrunning]

Correct me if I'm wrong, but there shouldn't be any issues de-typing HAL enums. The HAL and its dependencies are all compiled for the same system, so the internal size for the enum should be the same on both ends. If it does get implicitly cast to an int32_t at some point, surely just (int32_t)(enum) should do just fine, since enums are by C spec some form of integer.

Would it be worth switching struct foo {} to typedef struct {} foo in the HAL, rather than adding struct to every parameter/variable of type foo?

[ThadHouse]

The reasoning for the explicit sizing is the use case for the HAL being C is not for interfacing with a C compiler. It's more for dealing with interop between other languages that can only directly hook into C API's. Those don't normally directly use the headers, and having explicit sizes on everything helps make that interop work easier. Explicit sizing just makes sure that those other languages don't get unexpected changes to variable sizing, which could happen without explicit sizing.

[ThadHouse]

We could IfDef around all of those things to enable the headers to be parsable in pure C, but when actually compiling the HAL itself, or linking to C++, those explicit sizing definitions definitely should be there.
Note this is very much down my list of stuff to fix, so this is definitely an up for grabs issue, and tbh unless someone else picks it up, I probably won't get to it.