Jeff King <peff@xxxxxxxx> writes: > On Sun, Feb 16, 2014 at 05:22:45PM +0100, David Kastrup wrote: >> >> config.c:#undef config_error_nonbool >> config.c:int config_error_nonbool(const char *var) > > You could always look in the commit history: > > $ git log -S'#define config_error_nonbool' cache.h > > or search the mailing list: > > http://thread.gmane.org/gmane.comp.version-control.git/211505 > >> Presumably this was done so that the uses of config_error_nonbool can be >> recognized as returning -1 unconditionally. > > Yes, it helps prevent false positives in gcc's flow analysis > (specifically, -Wuninitialized warnings). > >> But is that worth the obfuscation? > > Yes? gcc's flow analysis works with the same data as humans reading the code. If there is no information content in the function call, it makes more sense to either making it void. One can always explicitly write (config_error_nonbool("panic-when-assailed"), -1) for shortcircuit use inside of an expression even when config_error_nonbool is a function returning a void expression: comma operators do not try type coercion on their first argument. Shrug. This one has likely been discussed to death already. Sometimes it's more convenient to avoid getting a question asked in the first place rather than having a stock answer for it. -- David Kastrup -- 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