Junio C Hamano wrote: > We could obviously do (2) or (3), but the thing is, I don't think we can > have much confidence on -Wuninitialized warnings from this compiler once > we go down that route. Is it _guaranteed_ that the compiler bug _always_ > err on the false-positive side? > > IOW, I'd very much prefer (1) for this particular case and if somebody > really cares (2). *nod*. The tricky heuristics here are that (A) a call to the function extern void foo(int *var); is assumed to initialize *var (to support idioms like strbuf_init), while (B) no assumption is made about the return value of a call to the function extern int bar(void); The assumption (B) is the scourge of -Wuninitialized users. It is always going produce a lot of false positives --- the compiler simply doesn't have enough information to completely analyze the flow through a function. (Even if it did have enough information, completely solving the problem is Turing-complete.) Problems from (A) are more rare. -Wuninitialized will produce _some_ false negatives, but problems it misses would typically be due to failure to check for errors and return early, which is not what -Wuninitialized is about. I don't mind the warning, especially since it only appears with -O3. What makes this interesting to me is that it is a reminder that the compiler has very little information about the flow of control. A simple #define error(...) (report_error(__VA_ARGS__), -1) could open the door to some nice micro-optimizations. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html