To summarize various replies in the thread:<p>This is a variation of an unfixed 2004 GCC bug. Clang detects the issue when the right warnings are enabled. Those warnings are disabled currently. A developer is auditing and fixing all such instances found by Clang so that they can reenable those warnings.
Explanation here (from 2004): <a href="https://gcc.gnu.org/ml/gcc/2004-12/msg00681.html" rel="nofollow">https://gcc.gnu.org/ml/gcc/2004-12/msg00681.html</a><p>It's not that GCC proves the uninitialized variable must be 0, it's just that CCP sets it to 0 and everything happens to work out in specific cases.
What I don't understand is why it doesn't optimize away the check on (inode->i_nlink), since it is assuming the code in the dependent block always runs.<p>It has to be assuming that, because it is the only path that doesn't lead to undefined behavior.
Aside: static analysis is a great initial effort but to really get confidence you should use techniques like sanitizers (MSan in this case) or valgrind. (This is general advice, not always applicable to kernels).
A simple way to avoid this problem is prohibit, in that code base, local variable declarations without initializers. If the initializer truly was unneeded the compiler would be able to eliminate it in almost all cases. Risking undefined behavior for hypothetical microspeedups is just dumb. If a case occurs where leaving out the initializer is both useful and safe then the initializer could be removed there, after deliberate review.
It look like a bug to me, since inode->i_nlink may be zero, and then ret is uninitialized (optimizing the final "return ret" to "return 0" should be safe (but is not necessarily worth it, depending on the target instruction set and ABI), although if warnings are enabled, it seem like the warning should still be displayed).