feat: added _Nonnull and _Nullable attributes to mujoco.h #1038
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The basics
git clang-format
The details
Resolves
mujoco.h
APIs #309Proposed Changes
New compilers, such as clang starts to support _Nullable attribute: https://clang.llvm.org/docs/AttributeReference.html#nullable
These can be #define away on unsupported compilers (For example, on GCC, you can define that as attribute((nonnull)): https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
Behavior Before Change
When using MuJoCo API, it is a bit harder to parse either automatically or from documentation when a parameter can be NULL or not. For example, mj_step requires mjData* d to be nonnull, while mj_copyData can take NULL mjData* dest. Similarly, mjv_makeScene can take NULL const mjModel* m. There seems to be no systematic way to understand which parameter can be NULL which cannot.
Behavior After Change
These nullability attributes can be helpful when generating interface glue code to MuJoCo library. For example, swift-mujoco right now assumes all fields to be nonnull and have to manually implement selected APIs that can be NULL. If nullability attribute added, these can be automatically generated like the rest of APIs.
Reason for Changes
When using MuJoCo API, it is a bit harder to parse either automatically or from documentation when a parameter can be NULL or not.
Test Coverage
I haven't tested this, as soon as I got confirmation that these are the required changes that will update the status of the Test Coverage.
Documentation
Additional Information