On Thu, Aug 11, 2022 at 8:05 AM Nathan Chancellor <nathan@xxxxxxxxxx> wrote:
>
> Right, these are exposed by commit 258fafcd0683 ("Makefile.extrawarn:
> re-enable -Wformat for clang").
Christ. Why is clang's format warning SO COMPLETELY BROKEN?
The warning is *WRONG*, for chrissake. Printing an 'int' with '%hhu'
is perfectly fine, and has well-defined semantics, and is what you
*want* to do in some cases.
I'm going to turn it off again, because honestly, this is a clang bug.
I don't care one whit if there are pending "fixes" for this clang bug,
until those fixes are in *clang*, not in the correct kernel code.
For chrissake, the value it is trying to print out as a char is '3'.
But even if it wasn't, and even if you wanted to print out "0xf365" as
a "char" value, then that is how C varargs *work*. It's an "int".
In fact, even a *character* is an "int". This program:
#include <stdio.h>
int main(int argc, char **argv)
{
printf("%hhu\n", 'a');
}
generates a warning with "clang -Wformat", and dammit, if you are a
clang developer and you see no problem with that warning, then I don't
know what to say.
Nathan, please make clang people see some sense.
Because no, I'm not in the least interested in getting kernel "fixes"
for this issue. -Wformat for clang goes away until people have gotten
their heads extracted from their derrières.
This is ridiculous.
Linus
