Make HAL headers C-compatible for FFIs #1122
Conversation
|
Can one of the admins verify this patch? |
4 similar comments
|
Can one of the admins verify this patch? |
|
Can one of the admins verify this patch? |
|
Can one of the admins verify this patch? |
|
Can one of the admins verify this patch? |
| * @link HAL_ENUM_END @endlink but uses @c int32_t as the type. | ||
| */ | ||
| #define HAL_ENUM_I32_START(name) HAL_ENUM_START(name, int32_t) | ||
| #define HAL_ENUM_I32_END(name) HAL_ENUM_END(name, int32_t) |
|
I think we're going to just make the enum parameters int32_t rather then the macro. That will probably be cleaner for most languages. |
Lytigas
force-pushed
the
c-compatible-hal-headers
branch
from
112bafa to
43b2228
Compare
|
@ThadHouse I would be happy to implement it, but can you elaborate on exactly what you mean? Are you referring to the macro itself or function signatures? |
|
The function signatures. Really not a fan of the macro, and its not 100% standard complaint either. Enums are not safe to pass as function parameters, and their size is implementation defined by the standards. That was the main reason for the sized enums in the first place. |
|
Theres also some suggestions on the Rust side here of how to deal with C enums, and they seem to suggest using fixed sizes as well. |
|
If all HAL function signatures take |
|
The HAL is explicitly not considered a user facing API. We often make breaking changes to it for the sake of either formatting, parameter passing, or changes in functionality. In addition, both the Java, the Python and the C# bindings all just take a raw 32 bit integer for the enum parameters, and then expect the higher level wrappers to hide this from users. Unsized enums are just not safe across ABI boundaries, and C has no proper way of declaring guaranteed size enums. Part of the reason for this is those other languages don't have easy FFI generators, so we actually end up manually writing them, and manually checking changes. Fixed sizes help immensely in FFI scenarios. Its the reason we use explicit types everywhere in the HAL, rather then just raw c types. |
|
Hm. What if we just |
| @@ -9,7 +9,10 @@ | |||
|
|
|||
| #include <stdint.h> | |||
|
|
|||
| #include <cstddef> | |||
| #include <stddef.h> | |||
There was a problem hiding this comment.
This should probably remain as cstddef in C++.
|
I've decided to pursue another way of getting |
Also fix the return type of HAL_IsNewControlData() and HAL_MatchType's type. Since UsageReporting is intended to be namespaced, it is hidden when this is being used in C. Fixes: wpilibsuite#476 Closes: wpilibsuite#535 Ref: wpilibsuite#1122
…ilibsuite#1122) On XboxControllers, moving the sticks upwards causes a negative change on the y-axis value, and vice versa. This means that driving a motor directly off the y-axis will result in inverted controls and cause difficulty (or damage, especially IRL). This resolves the issue by negating the y-axis in calls to the Joystick.
Allows for easy FFI's from other languages.
Overrides #535
Solves #476