Re: mainline build failure for arm64 allmodconfig with clang

From: Linus Torvalds
Date: Thu Aug 11 2022 - 11:47:11 EST


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