The local variables are not static but why do I get this behaviour?

Question

When I teach C, sometimes I count on GCC to do the "convincing" part of some rules. For example, one should not consider that a local variable on a function retains the value between calls.

GCC always helped me to teach these lessons to students, putting garbage on local variables, so they understand what is happening.

Now, this piece of code is definitely causing me a hard time.

#include <stdio.h>

int test(int x)
{
        int y;
        if(!x)
                y=0;
        y++;
        printf("(y=%d, ", y);
        return y;
}

int main(void)
{
        int a, i;

        for(i=0; i<5; i++)
        {
                a=test(i);
                printf("a=%d), ", a);
        }
        printf("\n");
        return 0;
}

The output is:

(y=1, a=1), (y=2, a=2), (y=3, a=3), (y=4, a=4), (y=5, a=5),

But if I comment the line:

       /* printf("(y=%d, ", y); */

Then the output become:

a=1), a=32720), a=32721), a=32722), a=32723),

I compile the code using -Wall switch, but no warnings are related to the use of local variables without initializing them.

Is there any GCC switch to cause a warning, or at least to explicit show some garbage? I tried the optimization switches, and that helped as the code output became like this:

$ gcc test.c -o test -Wall -Os
$ ./test 
(y=1, a=1), (y=1, a=1), (y=1, a=1), (y=1, a=1), (y=1, a=1),
$ gcc test.c -o test -Wall -Ofast
$ ./test 
(y=1, a=1), (y=1, a=1), (y=1, a=1), (y=1, a=1), (y=1, a=1),
$ gcc test.c -o test -Wall -O0
$ ./test 
(y=1, a=1), (y=2, a=2), (y=3, a=3), (y=4, a=4), (y=5, a=5),
$ gcc test.c -o test -Wall -O1
$ ./test 
(y=1, a=1), (y=1, a=1), (y=1, a=1), (y=1, a=1), (y=1, a=1),
$ gcc test.c -o test -Wall -O2
$ ./test 
(y=1, a=1), (y=1, a=1), (y=1, a=1), (y=1, a=1), (y=1, a=1),
$ gcc test.c -o test -Wall -O3
$ ./test 
(y=1, a=1), (y=1, a=1), (y=1, a=1), (y=1, a=1), (y=1, a=1),

But y=1 in all cases is kind of trick. Does the standard changed so the local variables are now initialized with zeros?

Answer 1

That's the problem with undefined behaviour: it's "undefined".

So, any set of results is entirely down to a combination of compiler/settings/what's in memory/interrupts.

You may chance upon some settings that output what you "expect", to demonstrate the problem - but that's just luck.

What you've discovered is actually more important - that the number of failure modes is wider than you can imagine (although luckily, none has reformatted your hard drive yet), and that the most pernicious and dangerous type of 'undefined behaviour' is that where the behaviour is actually 'as expected' for 99.99% of the time.

It's the 0.01% that gets you.

Answer 2

Your program causes undefined behaviour. If you pass a non-zero value to test(), y never gets initialized. printf included or not, you can't rely on the results.

If you want a warning, clang will give you one with -Wsometimes-uninitialized:

example.c:6:12: warning: variable 'y' is used uninitialized whenever 'if'
      condition is false [-Wsometimes-uninitialized]
        if(!x)
           ^~
example.c:8:9: note: uninitialized use occurs here
        y++;
        ^
example.c:6:9: note: remove the 'if' if its condition is always true
        if(!x)
        ^~~~~~
example.c:5:14: note: initialize the variable 'y' to silence this warning
        int y;
             ^
              = 0
1 warning generated.

I tested with a couple of GCC versions I have on-hand, but none of them would produce a warning for me.

Answer 3

Another possible approach to this idea might be to call another function in between calls to the test function. If the other function uses stack space, then it will likely end up changing the stack values. For example, perhaps add a function like this:

int changeStack( int x )
{
    int y2 = x + 100;
    return y2;
}

And then add a call to it:

    for(i=0; i<10; i++)
    {
            a=test(i);
            printf("a=%d), ", a);
            changeStack( i );
    }

It of course depends on optimization levels, but with the default gcc compile (gcc test.c), I got the following results after changing it to do that:

(y=1, a=1), (y=101, a=101), (y=102, a=102), (y=103, a=103), (y=104, a=104), (y=105, a=105), (y=106, a=106), (y=107, a=107), (y=108, a=108), (y=109, a=109),