[ArbitraryLimits]

Depends on the compiler. When I took my "hardware for CS students" class as an undergrad, our big project for the semester was to write a CPU simulator in c, and the campus labs had just rolled out the upgrade from gcc from 2.x to 3.x. I had a bug in my program that I just couldn't isolate, and after about eight hours of chasing it, I realized that the compiler had allocated space for an integer variable right in the middle of an already-allocated array, so the two variables were stomping on each other. I changed the name of the integer variable and my problems went away.

Apparently I wasn't the only one, because within a week all the labs were back on GCC 2.95.

[Figs]

Actually, that sounds a lot like a bug in your build system. Did you have a custom Makefile (either hand written, or provided by a teacher)? If you didn't keep track of dependencies very carefully so that you always recompile all the .c files that depended on shared .h files when the .h files change, you can wind up with situations where different object files disagree on the layout of structures -- it could cause exactly the sort of problem you describe. Changing the name of the variable could force the file to be recompiled, thus appearing to solve the problem.

[sounds]

To further support your point, the rollback to gcc 2.95 happened across many linux distributions due to incompatible changes in the language that happened at the gcc 3.0 version.

Many distributions rolled back so that the default "stable" compiler matched the one they had to use to build the packages - i.e. common sense.

Once the packages were updated to deal with the gcc 3.x language changes, the compiler and packages started appearing together.

[ArbitraryLimits]

I've seen that problem also (not pretty) but no, the two variables were from the same .c file, and were only used in that file.