On 2/25/19 6:58 PM, Linus Torvalds wrote: > On Mon, Feb 25, 2019 at 2:34 PM Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> On Mon, Feb 25, 2019 at 12:34 PM Hugh Dickins <hughd@xxxxxxxxxx> wrote: >>> >>> Seems like a gcc bug? But I don't have a decent recent gcc to hand >>> to submit a proper report, hope someone else can shed light on it. >> >> I don't have a _very_ recent gcc either [..] > > Well, that was quick. Yup, it's considered a gcc bug. > > Sadly, it's just a different version of a really old bug: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 > > which goes back to 2004. > > Which I guess means we should not expect this to be fixed in gcc any time soon. > > The *good* news (I guess) is that if we have other situations with > that pattern, and that lack of warning, it really is because gcc will > have generated code as if it was initialized (to the value that we > tested it must have been in the one basic block where it *was* > initialized). > > So it won't leak random kernel data, and with the common error > condition case (like in this example - checking that we didn't have an > error) it will actually end up doing the right thing. > > Entirely by mistake, and without a warniing, but still.. It could have > been much worse. Basically at least for this pattern, "lack of > warning" ends up meaning "it got initialized to the expected value". > > Of course, that's just gcc. I have no idea what llvm ends up doing. > Clang 7.0: # clang -O2 -S -Wall /tmp/test.c /tmp/test.c:46:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] if (inode->i_nlink) { ^~~~~~~~~~~~~~ /tmp/test.c:60:9: note: uninitialized use occurs here return ret; ^~~ /tmp/test.c:46:2: note: remove the 'if' if its condition is always true if (inode->i_nlink) { ^~~~~~~~~~~~~~~~~~~~ /tmp/test.c:37:9: note: initialize the variable 'ret' to silence this warning int ret; ^ = 0 1 warning generated.
