0

Let's assume that I'm programming this code in C. If I have an uninitialized variable number I can't know what will be its value. BUT...

WHAT IS that random value? What do I have in a memory dump? Is it because an address is tried to be read and nothing comes out?

I tried to debug my program but I'm still a newbie so I get lost easily. Also, if I add a zerowillcome variable (see Code 2) my number value won't be random anymore: it will be 0. I can't understand why this is happening but I think it regards the order variables are pushed onto the stack. Am I right? Can someone picture me what exactly is happening, step by step?

PS: Those other variables are there since this is a snippet of other code, so I do not know if removing them I'd be able to alter the application behaviour: my attention was caught by that strange behaviour caused by adding the zerowillcome variable.

Code 1:

int main (int argc, char *argv[])
{
    int number, var1, var2, tmp, tmp2;
        printf("number: %d", number); // <- insert random number here
        return 0;
}

Code 2:

int main (int argc, char *argv[])
{
    int number, var1, var2, tmp, tmp2, zerowillcome;
        printf("number: %d", number); // <- 0 !!!
        return 0;
}
Community
  • 1
  • 1
peperunas
  • 428
  • 1
  • 6
  • 17
  • Any results you get are not only undefined, but they're called undefined because they could change in the future. It's not really productive to know how the value got there today, when tomorrow it might not be there anymore. – mah Mar 21 '14 at 18:19

2 Answers2

1

WHAT IS that random value?

Generally, it's whatever value happens to have been left in that memory location by some previous function call.

When you call a function, one of the first things that happens is that the stack pointer is incremented to reserve the space needed for that function's return address, return value, and local variables. When the function exits, the stack pointer is decremented by the same amount. In between, that memory is used by the function to store data. After the function returns and some other function is called, the same thing happens, and the same memory may be used. If that function doesn't initialize its variables to some known value, the variables will happen to have whatever was left on the stack by the previous function.

You shouldn't care about this, though, and you certainly shouldn't rely on it. The value of an initialized variable is undefined, so it could be anything. A compiler could, for example, insert instructions that clear all the stack memory that a function uses before or after the function call. Or it could set the memory to the string "don't use uninitialized variables!" or anything else. The only rational approach is to make sure that you write some value into your variables (i.e. initialize them) before you ever read them.

Caleb
  • 124,013
  • 19
  • 183
  • 272
  • Also note, that on some systems, the kernel may use the unallocated stack memory to save state in a context switch, or may use it to run a signal handler. Both would clobber the data in the memory below the stack pointer in a way that can be triggered *at any point in the program from the outside*, and that is *entirely beyond the control of the process*. – cmaster - reinstate monica Mar 21 '14 at 19:02
0

It's undefined behaviour, your variables are not initialized at the time of their declaration.

user2485710
  • 9,451
  • 13
  • 58
  • 102
  • What is that number? Is it a hex representation? What do I see in a memory dump? – peperunas Mar 21 '14 at 18:13
  • @Krishath undefined behaviour means just that your compiler is allowed to take any route, thus you have an ill-formed program ( in the case this compiles ) . It's just junk. – user2485710 Mar 21 '14 at 18:15
  • 1
    @Krishath If you are using MSVC it most probably be hex 0xCCCCCCCC, MSVC programs auto fill uninitialized stack with 0xCC. – Aean Mar 21 '14 at 18:18
  • @Aean you should also remind that the C support in MSVC is not that great and this is not a good way of writing code. MSVC it's not going to generate better code if throw an undefined behaviour to it. – user2485710 Mar 21 '14 at 18:20
  • @user2485710 Yes obviously. But 0xCC sometimes help debugging. – Aean Mar 21 '14 at 18:22