Re: [PATCH] Fix an unitialized pointer in merge-recursive.c
- From
David Kastrup <dak@gnu.org>
- Date
- Aug 16, 2007, 09:07 UTC
- Message-ID
- <86643f4zlf.fsf@lola.quinscape.zz>
- In-Reply-To
- <7vodh7khuo.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 27 quoted lines
> "Marco Costalba" <mcostalba@gmail.com> writes: > >> On 8/16/07, Junio C Hamano <gitster@pobox.com> wrote: >>> "Marco Costalba" <mcostalba@gmail.com> writes: >>> >>> > Indeed &mrtree is passed to merge_trees() that not always >>> > seems to set the value, so on some paths mrtree could >>> > return uninitialized. >>> > >>> > Spotted by a gcc 4.2.1 warning >>> >>> Are you sure that gcc is correctly seeing the codeflow? >>> >>> In merge(), mrtree is used only under index_only, and >>> merge_trees() always sets *result under index_only. >> >> Ok ;-) >> >> Now two options: >> >> - discard the patch >> >> - change the title in 'silence a gcc bougus warning' > > Third option. Change the assignment from "mrtree = NULL" to > "mrtree = mtree". It is a standard idiom to work around stupid > gcc warnings.
I think it is more efficient to write mrtree = NULL: For the computer, it makes a minuscule difference, and it can save programmers a bit of confusion and worrying times. Time that may be better spent improving things elsewhere.
I don't think that we have a contest running for least redundancy in code layout, have we? Why then require the programmer to do a complete call trace analysis before he can feel comfortable about the code? And what if callers change at some point of time?
-- David Kastrup