The &quot;why&quot; for the second one is: that&#x27;s the model of the C language. Programs are translated in units. The semantic analysis ends when a translation unit is analyzed. All that is left is to resolve the external references when multiple units are linked; nothing is re-translated. This is very clearly stated in a few sentences in that section of the standard which describes the translation phases one by one.<p>Link-time optimization is a language extension which alters the concept of a translation unit. In some ways, multiple translation units become one unit (such as: they inline each other&#x27;s code, or code in one is altered based on the behavior of code in the other). But in other ways they aren&#x27;t one translation unit (e.g. their file scope static names are still mutually invisible.)<p>One reason I don&#x27;t use C99 is that many of its features aren&#x27;t C++ compatible. Most of C90 is. With just a little effort, a C90 program compiles as C++ and behaves the same way, and no significant features of C90 have to be wholly excluded from use.<p>Portability to C++ increases the exposure of the program to more compilers, with better safety and better diagnostics.<p>In some cases, I can use constructs that are specially targetted to C or C++ via macros. Instead of a C cast, I can have convert(type, val) macro which uses the C++ static_cast when compiled as C++, a coerce(type, val) which uses reinterpret_cast, or strip_qual(type, val) which uses const_cast. I get the diagnostics under C++, but the code still targets C. I&#x27;m also prevented from converting from void * without a cast, and there are other benefits like detecting duplicate external object names.<p>This way of programming in C and C++ was dubbed &quot;Clean C&quot; by the Harbison and Steele reference manual.<p>C90 is a cleaner, smaller language than C99 without extraneous &quot;garbage features&quot; like variable-length arrays that allocate arbitrary amounts of storage on the stack without any way to indicate failure to do so.<p>The useful library extensions in C99 like snprintf or newer math functions can be used from C90; you can detect them in a configure script like any library.<p>The overall main reason is that I simply don&#x27;t have faith in the ISO C process. The last good standard that was put out was C90. After that, I don&#x27;t agree with the direction it has been taking. Not <i>all</i> of it is bad, but we should go back to C90 and start a better fork, with better people.<p><pre><code>   git checkout -b c90-fork c90
   git cherry-pick ... what is good from c99-branch</code></pre>