Shot myself in the foot, but gcc provided the bullets!

Alternate title: "Another great candidate for a warning message"

So I was testing a program and noticed some really weird behavior. It was acting as if some boolean values had been set to 'true', though I was certain that they had not been. Incredulous, I decided to print them out. To my suprise, the output was something like:

96
34
71

I started to panic - surely this was a sign of major stack corruption! Just as I was about to fire up the debugger I decided to recheck the class, just for good measure. Then I spotted it:

Code:

struct foo
{
    foo( bool enable )
    : enabled( enabled )
    {    }
// ...
};

Ack - I was initializing the member with itself!

I wonder why gcc didn't issue a warning, though? I mean, when would you *ever* need to do such a thing, anyway? Let's see...never! I've got just about every warning turned on, too, even -Wunused (which should have been triggered, I would think).

So, in essence, you screwed yourself?

Well if you just change bool enable to bool enabled then the bug goes away. So it's not that common an error. And usually a misspelled variable results in a undeclared identifier error.

But yeah, making this a warning would not hurt.

It's called "-Winit-self". (Sorry: -Winit-self. I'll get this habit started eventually.)

Hmm...It doesn't seem to work, though (except for variables declared within functions). I'll keep looking around, though.

Well, interestingly enough, I can't get it to complain about an initializer list either. If I use -Wunused, I do get two warnings about unused parameter enable, though.

OOH Update: The above was true on my gcc 3.4.5 in MinGW. Using gcc 4something on the Mac, I get this:

Code:

$ g++ -Wunused -Wuninitialized -O1 -Winit-self -o warns warns.cpp 
warns.cpp: In function ‘int main()’:
warns.cpp:12: warning: ‘baz$enabled’ is used uninitialized in this function
warns.cpp:12: warning: ‘bar$enabled’ is used uninitialized in this function

So I lost the unused warning, but gained uninitialized warnings. Apparently how the optimizations go is important.

(For the curious, the code:

Code:

include <iostream>

struct foo {
    bool enabled;
    foo( bool enable ) :
        enabled(enabled)
    {  }
};

int main() {
    foo bar(true), baz(false);
    std::cout << bar.enabled << " " << baz.enabled << std::endl;
    return 0;
}

Still nothing. I'm using g++ 4.4.0, too.

Ok, so this is weird. If I use the -Wunused switch, no warning, but with -Wextra (with or without -Wunused), I get an unused variable warning!

I'm still going to look around to see if I can get it to detect self-initialization, though.

EDIT: Well, I've gone through all of the *documented* switches, but didn't find any that would help. Next step I guess would be to check the undocumented ones. At any rate, it probably should have tripped on -Winit-self, so I may need to report it to the mingw bugtracker anyway...

Thanks for your help, Tabstop!

This is also curious behavior:

Code:

#include <iostream>

struct foo {
	int member_fxn(){ int i = i; return i; } // no warning
};

int fxn(){ int i = i; return i; } // generates warning

int main() {
    
    return 0;
}

pertinent portion of makefile:

Code:

CXXFLAGS:= -O -Winit-self -Wall -Wextra -pedantic

Note that -O must be present, or no warnings are produced at all.

GCC only enables its flow analyzer if it optimizes at all. So if you use -O0 or no -O option, you don't get a flow analyzer. Without a flow analyzer, you don't get warnings about uninitialized variables. (As well as some other issues, such as aliasing violations.)