Putting the second if inside the body of the first is not necessarily equivalent.

g() might have side-effects, and those side-effects have to happen regardless of whether or not f() returned true.

Then the correct code was something like:

    if (f()) {
        int x = 1;

        if (g()) {
            h(x);
        }

    } else {
        g();
    }

If g() can be called before f() then it could also be written as:

    int g_flag = g();

    if (f()) {
        int x = 1;

        if (g_flag) {
            h(x);
        }
    |

If you really only had one assignment to x, and both f() and g() have side effects that must be run in-order, this can be more clearly written as:

    int f_flag = f(); // force f() to run for ${reasons}
    int g_flag = g(); // force g() to run for ${reasons}

    if (f_flag && g_flag) {
        h(1);
    }

This is a lot clearer about what the code is doing, and the compiler is probably going to optimize away the two int flag variables anyway.

You should never rely on uinitialized values not just because of the problems relating to undefined behavior, but also because you're adding in assumptions about the runtime state. The code depended on the return value of f() but did not fully express that dependency in the code.

It's true that if the only change you make is wrapping braces from "x = 1;" through the end of the quoted code, you would need to be sure that g does not have desired side effects. Otherwise, you could lift both the f() and g() calls above the branching (which still leaves the second if inside the body of the first, as I described).

Valid as well.