Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

2017-01-09 Thread Stefan Beller
On Sun, Jan 8, 2017 at 5:25 PM, Junio C Hamano wrote: > So with the above, are you saying "Dscho said 'hopefully', and I > confirm that this change does squelch misdiagnosis by Coverity"? I could not find the coverity issue any more. (It really misses easy access to "recently

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

2017-01-08 Thread Johannes Schindelin
Hi, On Sun, 8 Jan 2017, Junio C Hamano wrote: > How about explaining it like this then? > > (only the log message has been corrected; diff is from the original). > > commit c9bb5d101ca657fa466afa8c4368c43ea7b7aca8 > Author: Johannes Schindelin > Date: Mon Jan 2

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

2017-01-08 Thread Jeff King
On Sun, Jan 08, 2017 at 05:25:00PM -0800, Junio C Hamano wrote: > > If this patch is only to appease coverity (as the commit message eludes > > to) I think this may be a bad idea for upstream. If this patch fixes an > > actual problem, then the commit message needs to spell that out. > > That

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

2017-01-08 Thread Junio C Hamano
Stefan Beller writes: > On Mon, Jan 2, 2017 at 8:22 AM, Johannes Schindelin > wrote: >> Technically, it is correct that git_exec_path() returns a possibly >> malloc()ed string. Practically, it is *sometimes* not malloc()ed. So >> let's just use a

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

2017-01-04 Thread Stefan Beller
On Tue, Jan 3, 2017 at 1:33 PM, Johannes Schindelin wrote: > > This patch was originally only to appease Coverity, but it actually *does* > plug a very real memory leak: previously, *every* call to git_exec_path() > *possibly* returned a newly-malloc()ed buffer. Now,

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

2017-01-04 Thread Johannes Schindelin
Hi Stefan, On Tue, 3 Jan 2017, Stefan Beller wrote: > On Mon, Jan 2, 2017 at 8:22 AM, Johannes Schindelin > wrote: > > Technically, it is correct that git_exec_path() returns a possibly > > malloc()ed string. Practically, it is *sometimes* not malloc()ed. So > >

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

2017-01-03 Thread Jeff King
On Tue, Jan 03, 2017 at 12:11:25PM -0800, Stefan Beller wrote: > On Mon, Jan 2, 2017 at 8:22 AM, Johannes Schindelin > wrote: > > Technically, it is correct that git_exec_path() returns a possibly > > malloc()ed string. Practically, it is *sometimes* not malloc()ed.

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

2017-01-03 Thread Stefan Beller
On Mon, Jan 2, 2017 at 8:22 AM, Johannes Schindelin wrote: > Technically, it is correct that git_exec_path() returns a possibly > malloc()ed string. Practically, it is *sometimes* not malloc()ed. So > let's just use a static variable to make it a singleton. That'll

[PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

2017-01-02 Thread Johannes Schindelin
Technically, it is correct that git_exec_path() returns a possibly malloc()ed string. Practically, it is *sometimes* not malloc()ed. So let's just use a static variable to make it a singleton. That'll shut Coverity up, hopefully. Signed-off-by: Johannes Schindelin ---