On 08/22/2012 06:38 PM, Joachim Schmitz wrote: > > >> -----Original Message----- >> From: Junio C Hamano [mailto:gitster@xxxxxxxxx] >> Sent: Tuesday, August 21, 2012 4:06 AM >> To: Joachim Schmitz >> Cc: 'Johannes Sixt'; 'Jan Engelhardt'; git@xxxxxxxxxxxxxxx >> Subject: Re: git on HP NonStop >> >> "Joachim Schmitz" <jojo@xxxxxxxxxxxxxxxxxx> writes: >> >>> OK, so let's have a look at code, current git, builtin/cat-file.c, >>> line 196: >>> void *contents = contents; >>> >>> This variable is set later in an if branch (if (print_contents == >>> BATCH), but not in the else branch. It is later used always under the >>> same condition as the one under which it is set. >>> Apparently is is malloc_d storage (there a "free(content);"), so >>> there's no harm al all in initializing it with NULL, even if it only >>> appeases a stupid compiler. >> >> It actually is harmful. See below. > > Harmful to initialize with NULL or to use that undefined behavoir? > > I checked what our compiler does here: after having warned about "vlues us > used before it is set: it actually dies seem to have initializes the value > to 0 resp. NULL. > So here there's no harm done in avoiding undefined behavior and set it to 0 > resp NULL in the first place. > There is harm in tricking future programmers into thinking that the initialization actually means something, which some of them do. It's unlikely that you're the one to maintain that code forever, and the "var = var" idiom is used widely within git with a clear meaning as a hint to programmers who read a bit of git code. If they aren't used to that idiom, they usually investigate it in the code and pretty quickly realize that what it means. -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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