Surely that's too simplistic - consider a header containing:
#undef FOO
#define FOO 17
Assuming a prior definition of FOO (to something other than 17), one
could easily see the compilation succeed, yet no longer be producing
the correct program).
Or a header that contains:
int a=1;
And everywhere else (possibly in the same compilation unit, if needed)
there's:
int a;
Many other potential problems exist
A far more likely potential problem in my opinion is if the header contains:
double foo(...)
Then with the default options on a lot of compilers (or with C89
conformance added to the defaults) the compiler will *not* complain, it
will just silently compiler the code with what is now undefined
behaviour which may or may not work. If foo currently returns an int it
is even worse, because then (if the parameters are not a problem) it
*will* work until foo() the return type of foo is changed.
Which is not to say that sort of things is good programming practice
(and frankly most dependencies like that probably reflect poor
design), but we've all seen really bizarre stuff in headers, no?
You don't need bizarre stuff in the header for commenting it out to
silently cause problems. Simple good practice can do it.
The OP would be well advised to ensure that the compiler is told to warn
about functions being called without a prototype in scope, and as much
else as possible. This will help catch problems where a header is *not*
included (directly or indirectly) but is needed. How to do this (and if
it is possible) is compiler dependant and so should be asked on a group
dedicated to the compiler.