On Thu, Mar 21, 2013 at 08:19:43AM -0700, Junio C Hamano wrote:
> > $ git grep '#define uninitialized_var' include/
> > include/linux/compiler-gcc.h:#define uninitialized_var(x) x = x
> > include/linux/compiler-intel.h:#define uninitialized_var(x) x
> > but they recently had a discussion, e.g.
> > http://thread.gmane.org/gmane.linux.kernel.openipmi/1998/focus=1383705
> > so...
> While flipping the paragraphs around before sending the message out
> I managed to lose the important one. Here is roughly what I wrote:
> I am for dropping "= x" and leaving it uninitialized at the
> declaration site, or explicitly initializing it to some
> reasonable starting value (e.g. NULL if it is a pointer) and
> adding a comment to say that the initialization is to squelch
> compiler warnings.
I'd be in favor of that, too. In many cases, I think the fact that gcc
cannot trace the control flow is a good indication that it is hard for a
human to trace it, too. And in those cases we would be better off
restructuring the code slightly to make it more obvious to both types of
Two patches to follow.
[5/4]: fast-import: clarify "inline" logic in file_change_m
[6/4]: run-command: always set failed_errno in start_command
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html