Posted May 23, 2011 5:09 UTC (Mon) by khim
In reply to: What Every C Programmer Should Know About Undefined Behavior #3/3
Parent article: What Every C Programmer Should Know About Undefined Behavior #3/3
Typically giving extra arguments isn't a problem, but the standard says that without a prototype that's undefined behavior and therefore compiler is in rights to generate in that situation "nasal daemons"...?
Yup. That's correct. If your platform uses any form of Callee clean-up by default then your program indeed will blow up (typically it'll generate SIGSEGV but it's not guranteed).
Program is still valid if bar() is never called: undefined behavior only makes program invalid when it's actually executed.
This is true for any other cases as well. Compiler starts with the set of undefined behaviors and a promise from the programmer: this is program in C (or C++) and that means it does not trigger undefined behavior. How exactly programmer avoids undefined behavior is not important: perhaps there are some math or even command line options. It's not important. The important fact is that program does avoid the undefined behaviors and so all code paths which trigger it can be safely reduced/removed: they can not ever be executed so it's safe. Good compilers have few passes which are dedicated to propagate undefined behavior "back" (if access to some variable always trigger undefined behavior that it's never accessed so there are no need to even calculate it and that means some function calls can often be removed, etc).
to post comments)