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 fixed" problems)
>
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 17:22:33 2017 +0100
>
> g
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 is
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 static variable to make it a singleton. That'll s
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, the first call will
> store th
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
> > let's just use a static variable
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. So
> > let's just use a static
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 shut
> Coverity up, hopefully.
8 matches
Mail list logo