Thanks for the PR but the existing function signatures look correct to me so it would be great if you could explain the problem and solution. Instead of this change, would a simple static_cast<char>(0x1f) do?

On most ARM 64‑bit ABIs char is signed by default. When the parameter type is char, the expression c >= 0 && c <= 0x1f is evaluated as two separate comparisons:

• c >= 0 because c is a signed integer, any value that fits in a char is already ≥ 0 (the range is –128 … 127). Therefore the compiler can prove that this part of the condition is always true and emits the warning.
• c <= 0x1f this part is still useful, because it checks whether the value falls in the control‑character range (0 … 31).

So the warning is not about a bug in the logic; it is just telling that the first sub‑expression does nothing.

If you want to keep the interface with char we can cast to an unsigned type for the comparison

constexpr bool is_ascii_control_char(char c) {
    return static_cast<unsigned char>(c) <= 0x1f;
}

On most ARM 64‑bit ABIs char is signed by default

I think there's a mixup in your explanation and you meant that it's unsigned by default.

Thank you — I understand the problem now.

Example of a warning with GCC (targeting aarch64):

test.cpp:2:57: warning: comparison is always true due to limited range of data type [-Wtype-limits]
    2 | constexpr bool is_ascii_control_char(char c) { return c >= 0 && c <= 0x1f; }
      |                                                       ~~^~~~

We can also get this warning if signedness is specified to be unsigned on the command line (--unsigned-char).

The warning does not show up with only -Wall -Wpedantic — we need -Wextra or just -Wtype-limits.