What's the behavior of an uninitialized variable used as its own initializer?

I noticed just now that the following code can be compiled with clang/gcc/clang++/g++, using c99, c11, c++11 standards.

int main(void) {
    int i = i;
}

and even with -Wall -Wextra, none of the compilers even reports warnings.

By modifying the code to int i = i + 1; and with -Wall, they may report:

why.c:2:13: warning: variable 'i' is uninitialized when used within its own initialization [-Wuninitialized]
    int i = i + 1;
        ~   ^
1 warning generated.

My questions:

• Why is this even allowed by compilers?
• What does the C/C++ standards say about this? Specifically, what's the behavior of this? UB or implementation dependent?

Solution 1:

Because i is uninitialized when use to initialize itself, it has an indeterminate value at that time. An indeterminate value can be either an unspecified value or a trap representation.

If your implementation supports padding bits in integer types and if the indeterminate value in question happens to be a trap representation, then using it results in undefined behavior.

If your implementation does not have padding in integers, then the value is simply unspecified and there is no undefined behavior.

EDIT:

To elaborate further, the behavior can still be undefined if i never has its address taken at some point. This is detailed in section 6.3.2.1p2 of the C11 standard:

If the lvalue designates an object of automatic storage duration that could have been declared with the register storage class (never had its address taken), and that object is uninitialized (not declared with an initializer and no assignment to it has been performed prior to use), the behavior is undefined.

So if you never take the address of i, then you have undefined behavior. Otherwise, the statements above apply.

Solution 2:

This is a warning, it's not related to the standard.

Warnings are heuristic with "optimistic" approach. The warning is issued only when the compiler is sure that it's going to be a problem. In cases like this you have better luck with clang or newest versions of gcc as stated in comments (see another related question of mine: why am I not getting an "used uninitialized" warning from gcc in this trivial example?).

anyway, in the first case:

int i = i;

does nothing, since i==i already. It is possible that the assignment is completely optimized out as it's useless. With compilers which don't "see" self-initialization as a problem you can do this without a warning:

int i = i;
printf("%d\n",i);

Whereas this triggers a warning all right:

int i;
printf("%d\n",i);

Still, it's bad enough not to be warned about this, since from now on i is seen as initialized.

In the second case:

int i = i + 1;

A computation between an uninitialized value and 1 must be performed. Undefined behaviour happens there.

Solution 3:

I believe you are okay with getting the warning in case of

int i = i + 1; 

as expected, however, you expect the warning to be displayed even in case of

int i = i;

also.

Why is this even allowed by compilers?

There is nothing inherently wrong with the statement. See the related discussions:

• Why does the compiler allow initializing a variable with itself?
• Why is initialization of a new variable by itself valid?

for more insight.

What does the C/C++ standards say about this? Specifically, what's the behavior of this? UB or implementation dependent?

This is undefined behavior, as the type int can have trap representation and you never have taken the address of the variable in discussion. So, technically, you'll face UB as soon as you try to use the (indeterminate) value stored in variable i.

You should turn on your compiler warnings. In gcc,

• compile with -Winit-self to get a warning. in C.
• For C++, -Winit-self is enabled with -Wall already.