-3

With the following code

#include <stdio.h>

int main() {

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

    int* num2;
    printf("%p\n", &num2);

    return 0;
}

I got result like:

enter image description here

From Memory allocation for global and local variables, I know the global variable num is initialized to 0 implicitly, even it is not initialized by me.

Now I am just trying something randomly, so I change the code to

#include <stdio.h>

int main() {

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

    int* num2;
    printf("%p\n", num2);

    return 0;
}

and now I get

enter image description here

Question: I don't know WHY the value of num is no longer 0.

In my opinion, what I am doing with the variable num2 and its value HAS NOTHING TO DO WITH the variable num.

I am not only interested why, but also want to hear your opinions about this behavior.

Community
  • 1
  • 1
user565739
  • 1,302
  • 4
  • 23
  • 46

2 Answers2

3
int num;
printf("%d\n", num);

int* num2;
printf("%p\n", num2);

In both cases above you are reading values of uninitialized variables (in one case this variable is simple integer, in other case pointer - but like I said in both cases their values are not initialized).

Local variables are not initialized by default.

Reading values of uninitialized variables is undefined behavior.

This was fine

int* num2;
printf("%p\n", &num2);

because &num is address of num pointer - it has defined value. Though more correct is to use:

   printf("%p\n", (void*) &num2);

In other cases too where you use %p.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Giorgi Moniava
  • 27,046
  • 9
  • 53
  • 90
  • `Reading values of uninitialized variables is undefined behavior.` No; only if they can contain trap-representations, such as floats. You might get undefined *results*, though. – wildplasser Aug 10 '16 at 12:53
  • 1
    @wildplasser hm I think on SO reading values of uninitialized variables is commonly referred as UB: http://stackoverflow.com/documentation/c/364/undefined-behavior/2576/reading-an-uninitialized-object-that-is-not-backed-by-memory#t=201608101257444574981 – Giorgi Moniava Aug 10 '16 at 12:55
  • @wildplasser where is dereference mentioned? – Giorgi Moniava Aug 10 '16 at 12:57
  • In the "article" you linked to. (it is even the title) – wildplasser Aug 10 '16 at 12:59
  • @wildplasser check it once again – Giorgi Moniava Aug 10 '16 at 12:59
  • I see. It *could* be a wrong interpretation of The Standard, though. (the docs are only a few days old) – wildplasser Aug 10 '16 at 13:06
  • @wildplasser http://stackoverflow.com/questions/11233602/what-will-be-the-value-of-uninitialized-variable – Giorgi Moniava Aug 10 '16 at 13:07
  • 1
    @wildplasser, if an object with automatic storage duration has no initializer then its initial value is indeterminate. The standard specifies that one of the ways a program has undefined behavior is if "The value of an object with automatic storage duration is used while it is indeterminate." (C2011, J.2) The analysis doesn't reach the question of whether the value is a trap representation. – John Bollinger Aug 10 '16 at 13:12
  • It must have been changed since C99. I stand corrected. The trap-reprentation was the rationale in the older standard, IIRC. – wildplasser Aug 10 '16 at 13:16
1

local variables without static keyword have automatic storage duration.num is one such variable.

And reading a value of a varibale with automatic storage before assigning any value to it can result in anything. So you cannot expect some determinate output.

And yes, as your code is, what you are doing with the variable num2 and its value HAS NOTHING TO DO WITH the variable num. But num2 and num can be relaed if you do num2 = &num;, after which what you you assign to *num2 will impact the value of num.

sps
  • 2,720
  • 2
  • 19
  • 38