gpio: Refactor use of RIOT's gpio_read() #132
Conversation
C callers of gpio_read() do not care whether gpio_read() returns an pre C99 style `bool` (which is an `int` with every non-zero number being a valid representation of `true`) or C99 style `bool`, as long as the stay within spec (treating representation of `true` as `true` with no regard to the encoding). This refactors the rust use to match the C behavior. This would allow updating `gpio_read()` to return C99 style `bool` as type.
There was a problem hiding this comment.
Thanks, LGTM.
(I do suspect that it's technically a breaking API change in C, and as we can't get rid of static inline right now I'd like it better if our macros were at least static inlines internally, but anyhow, for the given situation in RIOT, this seems to be the right fix).
|
Looking at the PR actually using this (RIOT-OS/RIOT#20936), my comment was misguided, and this is already an actual API (and a non-static function even). This does not alter the review assessment that this PR is doing the right thing, but had no simple |
C callers of gpio_read() do not care whether gpio_read() returns an pre C99 style
bool(which is anintwith every non-zero number being a valid representation oftrue) or C99 stylebool, as long as the stay within spec (treating representation oftrueastruewith no regard to the encoding).This refactors the rust use to match the C behavior. This would allow updating
gpio_read()to return C99 styleboolas type.