set default value for all uninitialized variables

Question

I have a legacy code where there are like a zillion uninitialized

warning C4100: : unreferenced formal parameter

or potentially uninitialized:

warning C4701: potentially uninitialized local variable used

variables, which can cause undefined behavior later down the line. Is there any way to tell the compiler to set all the uninitialized variables to something more debuggable like NULL. Probably using either of options

• preprocessing macros
• compiler options
• CMake options

For example, consider this dummy code:

#include <stdio.h>

int main() {

   int a;

   printf("%d\n",a);

   return 0;
}

I want to use either of the options above to set all cases like a to NULL or maybe in this case, 0 if NULL is not possible.

P.S. Here I'm using MSVC to catch the possible issues but in the end I want my solution to be cross platform and compiler agnostic. So compiler specific solutions (e.g., GCC, Clang...) are highly appreciated anyway.

Answer 1

This is prefaced by my top comments.

I've cloned your develop repo.

Eventually, I was able to do a make -i. The output was about 500 lines [of errors].

So, there aren't enough errors to justify an automated script (i.e. by the time you get the script to production quality, you can do manual examination and fixup in less time).

And, some of the errors should be examined for logic errors, notably -Wmaybe-unitialized, which is what you were concerned with. Now might be a good time to determine if just changing: int foobar; into int foobar = 0; is okay. If so, that's what I'd do. (i.e.) If the code, based on the if hierarchy, never actually uses the value when it's uninitialized, adding int foobar = 0; just tells the compiler to STFU about a non-problem.

But, it may actually be a bug. If the code path the warning is complaining about is taken. Perhaps the code path hasn't shown up in practice, but, with different input data [in the future], the code is executed. This would be a [latent] bug.

At a minimum, just initializing with = 0; would change unpredictable random side effects into predictable side effects. If the function fails, it will now fail in a consistent/predictable way (vs. relying on the random value it gets in the [uninitialized] stack frame).

But, this would be a good time to desk check the code for [latent] bugs. You'll get more attaboys ;-)

A number of errors were -Wunused-parameter. Normally, I add -Wno-unused-parameter to CFLAGS if the code is known to be working. IMO, this really isn't even a bug [real, imaginary, or theoretical] most of the time--it's not an error to not use a parameter, just a warning for newbies writing new code. If you have a function signature that has an extra parameter that you have to keep for backwards compatibility, but the replacement function doesn't need it, you'll get a false positive here.

For -Wunused-but-set-variable, I'd remove the declaration and the assignment to it. Triage against int result = important_function_that_changes_globals();. There, keep the function call. Replace with: important_function_that_changes_globals();. Or, if you must [and, personally, I never do this]: (void) important_function_that_changes_globals();

But, there are others that indicate bugs (e.g.) -Wstringop-truncation which is indicative of [possible] buffer overflow.

The code base in the src subdirectory is [only] 30,000 lines. Again, with only about 500 lines of error messages.

Based on my experience, the errors could be triaged in 1-3 days [and one week max].

But, as jarmod pointed out, there may be more serious errors [that only show up with runtime debugging].