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
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
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
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
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,
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
> >
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.
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
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
---
9 matches
Mail list logo