Re: mainline build failure due to 281d0c962752 ("fortify: Add Clang support")

[Sudip Mukherjee <sudipm.mukherjee@gmail.com>]

On Wed, Jun 22, 2022 at 11:07:40AM -0500, Linus Torvalds wrote:
> On Wed, Jun 22, 2022 at 11:00 AM Sudip Mukherjee
> <sudipm.mukherjee@gmail.com> wrote:
> >
> > imho, there is no check for 'i' and it can become more than MAX_FW_TYPE_NUM and
> > in that case it will overwrite.
> 
> No. That's already checked a few lines before, in the
> 
>         if (fw_image->fw_info.fw_section_cnt > MAX_FW_TYPE_NUM) {
>                 .. error out
> 
> path. And fw_section_cnt as a value is an unsigned bitfield of 16
> bits, so there's no chance of some kind of integer signedness
> confusion.

oops. yeah, sorry missed that.

> 
> So clang is just wrong here.
> 
> The fact that you can apparently silence the error with an extra bogus
> check does hopefully give clang people a clue about *where* clang is
> wrong, but it's not an acceptable workaround for the kernel.
> 
> We don't write worse source code to make bad compilers happy.
> 
> My "use a struct assignment" is more acceptable because at least then
> the source code doesn't get worse. It arguably should have been done
> that way the whole time, even if 'memcpy()' is the traditional C way
> of doing struct assignments (traditional as in "_really_ old
> traditional C").

Incidentally, its same as what Kees sent.

2c0ab32b73cf ("hinic: Replace memcpy() with direct assignment") in next-20220622.


--
Regards
Sudip