为什么gcc给我这个结果？

Question

When I run this code gcc gives me the output 10.

Can someone explain to me why it gives me 10? :)

#include <stdio.h>

int f(int x) {
    int y;
    y = 2*x;
}

int g() {
    int z;
    return z;
}

int main() {
    int x=5;
    f(x);
    printf("%d\n",g());
}

Answer 1

this is undefined behavior - you are referencing a variable which has no value set to it. likely, it gives 10 because the compiler has used the same memory location for the variable in f(), but there is no guarantee of that, it should not be depended on, and is nothing more than a curiosity.

Answer 2

There's nothing to explain. Your code exhibits undefined behaviour on two separate, unrelated occasions: First f isn't returning anything despite being declared as returning int , and second because g returns an uninitialized value.

Practically, the way the functions will be put on the call stack will have caused the local y (which eventually has the value 10 ) to be in the same place as the return value of g() in the printf call, so you happen to see the value 10 . But that's more or less a matter of luck.

Answer 3

Here:

int g() {
    int z;
    return z;
}

This reads:

int g():
    reserve memory for an integer, call it z.
    return whatever is in that reserved memory.

You never used that reserved memory for your integer. Its value is whatever was at that address before you chose to use it (or not use it, rather). That value could be anything.

You do the same in your other function. What you are doing is reading uninitialized memory. You can google that up for further information. See also the "stack" and the "heap", dynamic memory, and other related topics.

Answer 4

g从堆栈中返回一个单位化的变量，在您的示例中，位置最后由F函数设置，给您x * 2 = 10的答案

Answer 5

Because you're not initializing z, and it's using the same location on the stack as y. Since you're not initializing it the old value is still there.

Answer 6

This is a perfect example of why people fear optimizations and when they brag about finding compiler bugs to their bosses. This code as others have alluded to will throw warnings about using uninitialized variables in g() . With your compiler settings, it is using the old value on the stack from the call to f(5) . With different compiler optimization settings, it will likely have effects on how variables end up on the stack and you'll end up getting a different results when you make changes which appear unrelated. This is undefined behavior and there is no guarantees on what value will result however it is usually easy to explain by understanding the call order and how the compiler sets up the stack. If there are warnings when you're troubleshooting weird behavior like this, fix the warnings first then start asking questions about why.