Value assignment in C while declaring multiple variable in 1 line

Question

I was playing with the single line declaration and initialization of multiple variables and notices something out of ordinary in C

#include <stdio.h>

int main() {
    int a, c, d, e = 0;
    printf("a = %d, c = %d, d = %d, e = %d", a, c, d, e);
}

So the output of the above program was

a = 2961408, c = 0, d = 4200720, e = 0

Easy since e is assigned 0 and rest all may be garbage value but c has the value 0. I changed the code to

#include <stdio.h>

int main() {
    int a, b, c, d, e = 0;
    printf("a = %d, b = %d, c = %d, d = %d, e = %d", a, b, c, d, e);
}

and this time the output was:

a = 2297856, b = 0, c = 4200736, d = 4200848, e = 0

Again the second variable was initialized as 0 [Here b, previously c] along with e and rest all are garbage.

And the same thing was noticed for 3, 4, 5, 6, 7, and so on variables every time the second variable in the declaration is initialized the value 0 along with the last variable.

This is not the case of initialization of last variable but if I assign any variable after the second variable with value 0. My second variable get 0 as it's initialization value. Is it something wrong with my compiler or is there some logic behind this in C?

#include <stdio.h>

int main() {
    int a, b, c, d, e, g = 10, f;
    printf("a = %d, b = %d, c = %d, d = %d, e = %d, g = %d, f = %d", a, b, c, d, e, g, f);
}

Output:

a = 3702784, b = 0, c = 4200752, d = 4200864, e = 6422400, g = 10, f = 4200752

[P.S. My C compiler is gcc (MinGW.org GCC Build-2) 9.2.0 ]

Answer 1

Is it something wrong with my compiler

No.

or is there some logic behind this in C?

No.

Reading uninitialized local values give you indeterminate values. This is so-called undefined behavior - the first thing you need to understand is what that means. What is undefined behavior and how does it work? As I wrote there:

It is important to investigate the cause of the undefined behavior - not so much the symptoms. Beginners often ask why a certain behavior occurred when they did something undefined, but there is often not much to learn from investigating the outcome. Time is better spent on learning what caused the undefined behavior.

Now the reason why this is undefined behavior is actually because you didn't take the address of those uninitialized local variables, see this answer: (Why) is using an uninitialized variable undefined behavior? So the program might as well just crash.

That issue aside, on many systems indeterminate values manifest themselves as printing whatever happened to be stored at some random locations in RAM. The way RAM memory works, we never "delete" or "erase" anything from it. We just keep track of which locations that are used, then when they aren't used any longer, whatever happened to be stored there remains.

But there are no guarantees of anything so an optimizing compiler might just as well print the contents of some random CPU register. Again, there's nothing meaningful to learn from this. You might as well toss some dice and then try to find a reason why you got certain values.

Some bad compilers utilize a "debug build" where the whole RAM is set to zero, so on such systems you'll get all zeroes. This is bad since it hides away bugs until you switch from debug to release.

Anyway, the only thing important to learn from this is gcc/mingw would have whined about uninitalized variables in case you used -Wall. As a beginner, make a habit of compiling with:

gcc -std=c11 -pedantic-errors -Werror -Wall -Wextra