This answer only addresses GCC.

After further investigation and comments, there is more going on than in my previous answer. This code snippet has two uninitialized variables, and each of them is undetected for a different reason.

First of all, the GCC documentation for the -Wuninitialized option says:

Because these warnings depend on optimization, the exact variables or elements for which there are warnings depends on the precise optimization options and version of GCC used.

Previous versions of the GCC manual worded this more explicitly. Here's an excerpt from the manual for GCC 3.3.6:

These warnings are possible only in optimizing compilation, because they require data flow information that is computed only when optimizing. If you don't specify -O, you simply won't get these warnings.

It seems the current version may give some warnings without uninitialized variables without -O , but you still get much better results with it.

If I compile your example using gcc -std=c99 -Wall -O , I get:

foo.c: In function ‘NearEqual’: foo.c:15:21: warning: ‘tauxtrouve’ is used uninitialized in this function [-Wuninitialized] return tauxtrouve == tauxprecis ; // at this point tauxtrouve is potentially ^

(Note this is with GCC 4.8.2 as I don't have 4.9.x installed, but the principle should be the same.)

So that detects the fact that tauxtrouve is uninitialized.

However, if we partially fix the code by adding an initializer for tauxtrouve (but not for totaldiff ), then gcc -std=c99 -Wall -O accepts it without any warnings. This would appear to be an instance of the "bug" cited in haccks's answer.

There is some question as to whether this should really be considered a bug: GCC doesn't promise to catch every possible instance of an uninitialized variable. Indeed, it can't do so with perfect accuracy, because that's the halting problem. So warnings like this can be helpful when they work, but the absence of warnings does not prove that your code is free of uninitialized variables! They are really not a substitute for carefully checking your own code.

In the bug report linked by haccks, there is much discussion as to whether the bug is even fixable, or whether trying to detect this particular construct would result in an unacceptable false positive rate for other correct code.