gcc -Wmaybe-uninitialized

This is my rant-response to a thread claiming that this particular case is a WONTFIX... I'll put it here, instead.

Look at 'info gcc' under -Wmaybe-uninitialized (or -Wuninitialized)

Then try to hold your tongue as you read these thin excuses at places like:

http://stackoverflow.com/questions/17705880/gcc-failing-to-warn-of-uninitialized-variable

'has the phrase "Never going to be fixed" in the discussion'

I'm sorry, this "difficult" excuse is just downright awful and doesn't seem to fit with the general approach of GCC, as I've understood it.

Here's a REALLY SIMPLE and COMPLETE example:

#include <stdio.h>

#include <stdlib.h>

int main(void)

{

int result;

if(rand())

result = 1;

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

return 0;

}

Yes, rand() can return 0, it may be seldom, so how about "if ( rand() & 0x1 )" which should be zero 50% of the time...

Here are several test-builds:

$ avr-gcc -Os -Wuninitialized -o uninitializedTest uninitializedTest.c

$ gcc-4.2 -Os -Wuninitialized -o uninitializedTest uninitializedTest.c

$ gcc-4.0 -Os -Wuninitialized -o uninitializedTest uninitializedTest.c

uninitializedTest.c: In function ‘main’:

uninitializedTest.c:32: warning: ‘result’ may be used uninitialized in this function

$ gcc-4.2 -Os -Wmaybe-uninitialized -o uninitializedTest uninitializedTest.c

cc1: error: unrecognized command line option "-Wmaybe-uninitialized"

$ gcc-4.2 -Os -Wuninitialized -o uninitializedTest uninitializedTest.c

$ gcc-mp-4.8 -Os -Wuninitialized -o uninitializedTest uninitializedTest.c

$ gcc-mp-4.8 -Os -Wmaybe-uninitialized -o uninitializedTest uninitializedTest.c

avr-gcc is 4.8 (Also tested with avr-gcc-4.4.5)

It appears gcc-4.0 had the ability to recognize the problem. If that's the case, it should be an option in later versions. That would be the idea behind "maybe-uninitialized"

If they're so worried about "false positives" then maybe there should be a pragma or something for such functions that have specific arguments, as in the example where "only" 1, 2, or 3 "can be passed as an argument"

That whole concept is bunk, there's *nothing* limiting someone misusing that function-call with a 0-argument. And there's nothing different about this case than, say, "sprintf"'s potential for overflows, and the resulting fallout of such bugs. There's a reason they came up with snprintf, and why it's highly recommended in most cases now. Likewise, there's a reason some people choose options like -Werror=maybe-uninitialized only to find it's not doing what it says it should, when it *did* previously.

The code existed at one point to detect this sort of potential error, at least in gcc-4.0.

Here's my specs:

Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --program-prefix= --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9

Thread model: posix

gcc version 4.0.1 (Apple Inc. build 5493)

This "example" of a "difficulty" is nothing more than an excuse, a "decade-old" excuse. And for what? Was it an Apple-specific addition, that they hold license to? Can No One in the gcc developer community figure out how to do it their own way?

Maybe "maybe-uninitialized" should be reserved for such a case as described (1,2,3 arguments only). But then there should be another option, maybe "potentially-uninitialized".

In my case, the binary size jumped *dramatically* after nothing more than initializing the variable to 0. Hours of scouring the called functions for code-mistakes, assuming the optimizer had somehow determined they always returned non-zero, etc. What is this, some sort of initiation-game? Is this how you pick out developers?

Further, the example in the manual is not even compilable code, lacking a default case, which would render the example moot in the first place.

This whole experience, again, is the very reason a "default" case is *required*.

Some of us actually *rely* on these warnings doing what they say they do!