[barrkel]

No they don't. What UB do you think they invoke?

They do invoke implementation defined behaviour, but not undefined.

[DSMan195276]

An uninitialized variable is UB, not implementation-defined. Thus, the compiler is free to treat the variable as though it doesn't have a value at all, or change it's value at will. It's not uncommon for the value of an uninitalized variable to change at strange places in the code that you wouldn't expect, because the compiler initially said "Variable x will be kept in register %eax", but then without a value to initialize it too, it just uses whatever happens to be in %eax at the time. For example, if they compiled this:

    return x == (1 && x);

Into this:

    movl $0, %eax
    andl $1, %eax
    cmpl %eax, %eax
    # Result in %eax

That will (obviously) return 1 every time, because we compare %eax and %eax. The reason for this is that the value of 'x' changes half-way through the computation (Because the computation is done in %eax, which is where 'x' is assumed to be). This is valid because 'x' is uninitalized, so it doesn't have a defined value.

[barrkel]

What evidence do you have that it's an uninitialized variable?

It's a code fragment; it's not in a function body. The way I read it, it was simply to document the type of x. 'x' could be a global for all we know.

[DSMan195276]

My evidence is that the entire page is basically just to shows CIL's output on various pieces of code, and CIL's output is linked on the page and looks like this:

    /* Generated by CIL v. 1.3.7 */
    /* print_CIL_Input is true */

    #line 1 "cilcode.tmp/ex30.c"
    int main(void) 
    { int x ;

      {
    #line 2
      return (x == (x != 0));
    }
    }

From that I think it's safe to say that it's talking about 'x' being an uninitialized variable in a function (Because that's what they put into CIL). This code definitely has the issue from UB that I described above.