Clang tidy: round 2

[wismill]

CI will pass once #661 is merged.

EDIT: removed clang-tidy CI.

[wismill]

Well, no chance here. The clang-tidy on the runner seems too old for the current config. Maybe there is an action we can use or a runner with the expected clang-tidy version?

[wismill]

The issue is that my .clang-tidy config works only with the latest clang-tidy, 19.1 (see the release notes). It is not yet available in the Github runners (latest is 18.1 on Ubuntu 24.0.4).

Not sure I want to dig how to make it compatible with earlier versions, or maintain two config versions.

Maybe just deactivate it for now.

[wismill]

Removed the clang-tidy CI, we’ll deal with it in a further PR.

[bluetech]

LGTM

[bluetech]

IIRC setgroup->group is an int8_t, so why does clang-tidy wants a cast here?

[wismill]

The actual warning:

../src/x11/keymap.c:200:31: warning: 'signed char' to 'int32_t' (aka 'int') conversion; consider casting to 'unsigned char' first. [bugprone-signed-char-misuse]
  200 |         action->group.group = wire->setgroup.group;
      |                               ^
../src/x11/keymap.c:213:31: warning: 'signed char' to 'int32_t' (aka 'int') conversion; consider casting to 'unsigned char' first. [bugprone-signed-char-misuse]
  213 |         action->group.group = wire->latchgroup.group;
      |                               ^
../src/x11/keymap.c:226:31: warning: 'signed char' to 'int32_t' (aka 'int') conversion; consider casting to 'unsigned char' first. [bugprone-signed-char-misuse]
  226 |         action->group.group = wire->lockgroup.group;
      |                               ^

From the doc about bugprone-signed-char-misuse:

When the code contains an explicit signed char -> integer conversion, the human programmer probably expects that the converted value matches with the character code (a value from [0..255]), however, the actual value is in [-128..127] interval. To avoid this kind of misinterpretation, the desired way of converting from a signed char to an integer value is converting to unsigned char first, which stores all the characters in the positive [0..255] interval which matches the known character codes.

The issue is that int8_t is just a typedef, so we get this unrelated warning.

[wismill]

I added int8_t to the option CharTypdefsToIgnore in .clang-tidy to avoid the explicit cast.