Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 11 Aug 2022 08:39:36 -0700 | Subject | Re: mainline build failure for arm64 allmodconfig with clang |
| |
On Thu, Aug 11, 2022 at 8:05 AM Nathan Chancellor <nathan@kernel.org> 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
| |