* Arnd Bergmann <a...@arndb.de> wrote: > On Thu, Jun 22, 2017 at 9:59 AM, Ingo Molnar <mi...@kernel.org> wrote: > > > > So, to continue this side thought about uninitialized_var(), it is dangerous > > because the following buggy pattern does not generate a compiler warning: > > > > long uninitialized_var(error); > > > > ... > > > > if (error) > > return error; > > > > > > ... and still there are over 290 uses of uninitialized_var() in the kernel > > - and > > any of them could turn into a silent but real uninitialized variable bugs > > due to > > subsequent changes. > > Right, absolutely agreed on that. A related problem however is blindly > initializing variables to NULL to get rid of uninitialized variable warnings, > such as > > struct subsystem_specific *obj = NULL; > if (function_argument > 10) > goto err; > obj = create_obj(); > ... > err: > clean_up(obj->member); > > > I've seen a couple of variations of that problem, so simply outlawing > uninitialized_var() will only solve a subset of these issues, and ideally > we should also make sure that initializations at declaration time are > used properly, and not just to shut up compiler warnings.
Well, a deterministic crash on a NULL dereference is still (much) better than a non-deterministic 'use random value from stack and corrupt memory or crash' bug pattern, right? Also, static analysis tools ought to be pretty good about finding control flows where a NULL gets dereferenced. Thanks, Ingo