"potentially uninitialized local variable"???

Hi!

A program I've made has code similar to the following:

int main(int argc, char** argv)
{
    bool b;
    ClassForSomething* obj;

    (...);
    b = false;
    try
    {
        obj = new ClassForSomething(...);
        b = true;
    } catch(AnException* eFailed)
    {
        (...);
    };
    if(b)
    {
        b = false;
        try
        {
            result = obj->DoSomething();
            b = true;
        } catch(AnException* eFailedAgain)
        {
            (...);
        }
    (...)
}

The program is compiled using Visual C++ 2005 Express, with "Warning Level" set to "Level 4".

The compiler, then, issues this warning:

warning C4701: potentially uninitialized local variable 'obj' used

at the line containing:

            result = obj->DoSomething();

Um... am I doing something wrong If I understand this code correctly, obj never comes unitialized at this line (or never comes to this line at all). Anyone can shed a light on this for me, please :)

Answer this question

"potentially uninitialized local variable"???

Lugoff81
If new threw an exception, obj would never get a value. I don't know if that's what the compiler is thinking or not.
drainey
Oh yes, I can imagine that's what would happen. However, that's sorted out by "bool b". If "obj" is succesfully built, then b = true, else b continues to be false, and (in theory) the inner "result = obj->DoSomething()" would never be called. That's what I thought, at least. The compiler seems to think otherwise. Why could that be
Dion
Mark: You were right. Writing "ClassForSomething* obj = NULL;" solved the warning. I can't honestly see why, but it did. Heck, maybe it's better to have class pointers always initialized to something, even if it's NULL, just to be safe. Thank you very much!

Martin: I think I must disagree with you. If "obj" is not initialized because of an exception, b will never be "true", and the second try-catch block would never be entered. That's exactly my point.

- Izhido

EDIT: Received alert on Martin, but didn't see his post. Maybe it was a private msg...
LindaW567
Ah, I see. I think you're giving the compiler too much credit. It isn't paying that much attention to the range of possible values in your variables. It doesn't try to figure out what the state of one variable says about the state of some other variable. That's how you think, but not how the compiler thinks.

I can't follow the logic of your code fragment, but I like the technique of setting pointers to NULL to indicate that they aren't initialized. You can call delete on a NULL pointer, so clean up needn't care whether it got some other value.

Of course, I don't use W4, either. I know people who use W4 and treat warnings as errors, but I use W3. With W4, it seems like I end up convoluting my code just to make the compiler shut up.
Peter Doyle
The compiler doesn't correlate the values of obj & b - in other words, it's looking at them independently, and thus if it's possible that 'obj' could be uninitialized at some future use (without paying attention to the value of 'b'), it warns.

It is not easy to solve the general problem of determining which, of the possible code paths, is really possible.
"potentially uninitialized local variable"???

Answer this question