Hello All,
I found memory leak at exec_cmd.c in system_path function with valgrind.
After this patch valgrind doesn't show any memory leaks, but I'm not sure
that it is the best way to solve this problem. There are a couple of places
that uses system_path, if this way will be good, i'll make anothe
Signed-off-by: 0xAX
---
exec_cmd.c | 25 -
exec_cmd.h | 4 ++--
git.c | 12 +---
3 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 698e752..08f8f80 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -6,7 +6,7 @@
static c
For example some testing with valgrind:
1. pu (952f0aaadff4afca1497450911587a973c8cca02)
valgrind git help
==27034== Memcheck, a memory error detector
==27034== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==27034== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright
gcc under cygwin reports several warnings like this:
warning: implicit declaration of function 'memmem'
[-Wimplicit-function-declaration]
This has been observed under CYGWIN-32 with GCC 4.7.3 as well
as CYGWIN-64 with gcc v4.8.3-5 x86-64
Do not #define _XOPEN_SOURCE 600 for CYGWIN.
Reported-by
Hi,
On Fri, 21 Nov 2014, Philip Oakley wrote:
> From: "Johannes Schindelin"
>
> > On Thu, 20 Nov 2014, Philip Oakley wrote:
> >
> > > @@ -343,8 +346,10 @@ sub handleLinkLine
> > > } elsif ($part =~ /\.(a|lib)$/) {
> > > $part =~ s/\.a$/.lib/;
> > > push(@libs,
From: Hartmut Henkel
Signed-off-by: Hartmut Henkel
Signed-off-by: Ralf Thielow
---
Junio,
please apply this patch directly to your
tree.
Thanks!
po/de.po | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/po/de.po b/po/de.po
index 56263b4..5a93ea8 100644
On 23/11/14 14:16, Torsten Bögershausen wrote:
> gcc under cygwin reports several warnings like this:
> warning: implicit declaration of function 'memmem'
> [-Wimplicit-function-declaration]
> This has been observed under CYGWIN-32 with GCC 4.7.3 as well
> as CYGWIN-64 with gcc v4.8.3-5 x86-64
A recent update to the gcc compiler (v4.8.3-5 x86_64) on 64-bit
cygwin leads to several new warnings about the implicit declaration
of the memmem(), strlcpy() and strcasestr() functions. For example:
CC archive.o
archive.c: In function 'format_subst':
archive.c:44:3: warning: implicit d
Jeff King writes:
> ... Possibly because I do not know that those instructions
> are written down anywhere. We usually catch such things in review these
> days, but there are many inconsistent spots in the existing suite.
t/README has this
Don't:
- use '! git cmd' when you want to mak
Ramsay Jones writes:
> Just a quick heads-up on a recent cygwin breakage.
>
> I updated my (64-bit) cygwin installation yesterday and (along
> with many other packages) I noticed a new version of gcc (and
> presumably libc) was installed (gcc v4.8.3-5 x86-64).
> ...
> However, I haven't run any
0xAX writes:
> Hello All,
> I found memory leak at exec_cmd.c in system_path function with valgrind.
> After this patch valgrind doesn't show any memory leaks, but I'm not sure
> that it is the best way to solve this problem. There are a couple of places
> that uses system_path, if this way will
0xAX writes:
> Signed-off-by: 0xAX
> ---
The comment on names I've already mentioned elsewhere.
You need a better explanation than a "no log message", as you are
not doing "system-path memory leak fix".
You are doing a lot more. Perhaps the story would start like this:
system_path(): ma
Ramsay Jones writes:
> On 23/11/14 14:16, Torsten Bögershausen wrote:
>> gcc under cygwin reports several warnings like this:
>> warning: implicit declaration of function 'memmem'
>> [-Wimplicit-function-declaration]
>> This has been observed under CYGWIN-32 with GCC 4.7.3 as well
>> as CYGWIN
IMO, if you put an empty string "" you would be implying the same as
with a dot (git add . ).
The important thing is that "git add" without a pathspec returns an
error, as it has always done, mainly because it people tend to work
without gitignoring all the files they should, and allowing such
beh
Junio C Hamano @ 2014-11-24 00:51 ALMT:
> 0xAX writes:
>
>> Signed-off-by: 0xAX
>> ---
>
> The comment on names I've already mentioned elsewhere.
Yes, i understand about names.
>
> You need a better explanation than a "no log message", as you are
> not doing "system-path memory leak fix".
>
Signed-off-by: Alex Kuleshov
---
exec_cmd.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 698e752..7ed9bcc 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -13,7 +13,7 @@ const char *system_path(const char *path)
#else
static const c
I would love to have such tool included in the toolchain, but being
able to use it to edit all the ignore chain, defaulting to .gitignore.
Explain the reason in my case.
Usually, when ignoring stuff, you will probable ignore already your
IDE/Editor files using a global gitignore. And most of the t
On Mon, Nov 24, 2014 at 01:19:29AM +0600, Alex Kuleshov wrote:
>
> Signed-off-by: Alex Kuleshov
> ---
> exec_cmd.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/exec_cmd.c b/exec_cmd.c
> index 698e752..7ed9bcc 100644
> --- a/exec_cmd.c
> +++ b/exec_cmd.c
> @@
On Sun, Nov 23, 2014 at 10:10:47AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... Possibly because I do not know that those instructions
> > are written down anywhere. We usually catch such things in review these
> > days, but there are many inconsistent spots in the existing suite.
On Sat, Nov 22, 2014 at 10:20:10PM +0100, Torsten Bögershausen wrote:
> > I do not think there is a real _downside_ to using test_must_fail for
> > grep, except that it is a bit more verbose.
> We may burn CPU cycles
It adds a single if/else chain. If your shell does not implement that as
a fast
On Sun, Nov 23, 2014 at 2:19 PM, Alex Kuleshov wrote:
>
> Signed-off-by: Alex Kuleshov
> ---
> exec_cmd.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/exec_cmd.c b/exec_cmd.c
> index 698e752..7ed9bcc 100644
> --- a/exec_cmd.c
> +++ b/exec_cmd.c
> @@ -13,7 +13,7
Alex Kuleshov writes:
> Signed-off-by: Alex Kuleshov
So this one does not change the contract between the caller and the
callee. It does not change the fact that you need to explain your
change, though. The story should read something like this:
system_path(): always return a volatile re
From: "Johannes Schindelin"
> How about the following instead?
>
> + } elsif ($part eq 'invalidcontinue.obj') {
> + # ignore
> } elsif ($part =~ /\.(o|obj)$/) {
Looks good, I'll use that (after deciding whether .obj files should
be
expected in a 'make' output anyway)
My idea to hardcode inva
On 23/11/14 18:13, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> Just a quick heads-up on a recent cygwin breakage.
>>
>> I updated my (64-bit) cygwin installation yesterday and (along
>> with many other packages) I noticed a new version of gcc (and
>> presumably libc) was installed (gcc v4.8
On 23/11/14 18:53, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> On 23/11/14 14:16, Torsten Bögershausen wrote:
>>> gcc under cygwin reports several warnings like this:
>>> warning: implicit declaration of function 'memmem'
>>> [-Wimplicit-function-declaration]
>>> This has been observed u
The RFC says that they are to be concatenated after decoding (i.e. the
intervening whitespace is ignored).
I change the sender's name to an all-Cyrillic string in the tests so that
its encoded form goes over the 76 characters in a line limit, forcing
format-patch to split it into multiple encoded
Hi, I wanted to chime in on the topic of SHA1 weaknesses and breaks. The
problem is idea that SHA1 breaks are theoretical and will only be
relevant in a decade or two.
I think its a telling sign when even companies like Google [1] and
Microsoft [2] who collaborate with spy agencies are moving
On Tue, Nov 18, 2014 at 4:26 AM, Jeff King wrote:
> Yes, it is only as "safe as SHA-1" in the sense that you have GPG-signed
> only a SHA-1 hash. If somebody can find a collision with a hash you have
> signed, they can substitute the colliding data for the data you signed.
I wonder if we can have
Best k'itchens offers reviews i could give are that you don’t pay until the
k'itchen is delivered.
-
Kitchen Offers Reviews
--
View this message in context:
http://git.661346.n2.nabble.com/K-itchen-Offers-Reviews-tp7621702.html
Sent from the git mailing list archive at Nabble.com.
--
To un
Jeff King:
>If I am reading this right, calls to system_path() will always reuse the
>same buffer, even if they are called with another "path" argument. So
>all callers must make sure to make a copy if they are going to hold on
>to it for a long time. Grepping for callers shows us saving the res
On 2014-11-24 00.15, Ramsay Jones wrote:
> On 23/11/14 18:53, Junio C Hamano wrote:
>> Ramsay Jones writes:
>>
>>> On 23/11/14 14:16, Torsten Bögershausen wrote:
gcc under cygwin reports several warnings like this:
warning: implicit declaration of function 'memmem'
[-Wimplicit-fu
On Sun, Nov 23, 2014 at 3:50 PM, Роман Донченко wrote:
> The RFC says that they are to be concatenated after decoding (i.e. the
> intervening whitespace is ignored).
>
> I change the sender's name to an all-Cyrillic string in the tests so that
> its encoded form goes over the 76 characters in a li
[jc: added those who were mentioned but were missing back to Cc]
On Sun, Nov 23, 2014 at 11:02 PM, Alex Kuleshov wrote:
>
> Junio C Hamano:
>
>>Fixing these callers are done as separate patches, that can be
>>applied either before or after this patch.
>
> How to do it better? Update this patch, f
33 matches
Mail list logo
