You do seem to have spent some time learning about compilers and looking at the code that they generate. However you have made a classic error of youth, you have relied upon sophomoric logic based upon anecdotal evidence from your debugging. This is not all in all a bad thing -- but you need to learn not to jump to conclusions about what you find.
I'm 19 and I'm sure i know how they work.
The C and C++ languages both leave a good many things as "implementation defined" or "undefined". Both terms basically mean the same thing - that it is up to the compiler or library vendor to determine how something is done. However things that are "implementation defined" means that the vendor has to define what will happen. When something is "undefined" the vendor is free to do whatever they want so long as they adhere to all the things that are defined.
Of course you are correct that no responsible compiler vendor is going to make a compiler that is going to generate code to format the hard drive just because you did something undefined. If they did they would quickly wind up in court. However, they would STILL be able to state with confidence that their compiler was "standards compliant" (not that it would be much of a defense).
Whenever you rely upon undefined behavior you are taking a big risk. One that has burned many companies who have discovered that their programs don't function on new platforms or on computers different from the development platform. Someone described it as "walking on thin ice" -- it might work 1000 times and then come crashing down. Indeed this happens.
So don't stop learning. But don't dismiss those of us who have been around for a while. Most of us have learned from many mistakes!