Messages in this thread | | | Date | Wed, 22 Jun 2022 17:16:43 +0100 | From | Sudip Mukherjee <> | Subject | Re: mainline build failure due to 281d0c962752 ("fortify: Add Clang support") |
| |
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
| |