On 08/22/2012 06:38 PM, Joachim Schmitz wrote:
>> -----Original Message-----
>> From: Junio C Hamano [mailto:gits...@pobox.com]
>> Sent: Tuesday, August 21, 2012 4:06 AM
>> To: Joachim Schmitz
>> Cc: 'Johannes Sixt'; 'Jan Engelhardt'; git@vger.kernel.org
>> Subject: Re: git on HP NonStop
>> "Joachim Schmitz" <j...@schmitz-digital.de> 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.erics...@op5.se
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to