Yes, these are lint questions. And yes, most compilers has an option to select char to be signed/unsigned.

But mixxing signed/unsigned is something quite a number of compilers will warn about even without lint. In the end, a programmer has to learn why lint (or the compiler) warns, and learn how to write code that does not give lint a reason to warn.

Just learning that a specific lint warning doesn't represent an error with the source code may later fool a user to write similar code for a different processor or compiler where the lint warning actually represent an error.

An interesting thing with signed/unsigned characters - how to iterate through all possible character values? -128 .. 127 or 0 .. 255 are quite different ranges. A type cast will in this case change the order of the iteration. And comparisons between signed/unsigned characters may result in impossible comparisons. A native character >= 128 may look like a negative value, in which case the copmiler can deduce that an unsigned character can never be negative so what looked like a perfectly good comparison got converted to "always false" by the compiler.

In the end, the lint warnings are not just arbitrary noise. They do represent situations where the developer has been playing with a dice. The code may sometimes be correct, and sometimes not. But the developer who wrote the code showed a very good indication of not knowing that a dice was thrown and would probably not be able to figure out under which conditions something that looked ok suddenly became an error. That is a big reason why it is better to fix the code (even if it will run ok) than to turn off lint warnings. The world does not need more programmers who depends on dices to decide if the code will work or not.