Re: [PATCH] column: use utf8_strnwidth() to strip out ANSI color escapes

Am 14.10.19 um 13:13 schrieb Johannes Schindelin: > Hi René, > > On Sun, 13 Oct 2019, René Scharfe wrote: > >> This changes the behavior, though: The old code skips all kinds of >> Control Sequence Introducer sequences, while utf8_strnwidth() only skips >> the Sele

[PATCH] remote-curl: use argv_array in parse_push()

array anyway. Signed-off-by: René Scharfe --- remote-curl.c | 22 +- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/remote-curl.c b/remote-curl.c index 051f26629d..1612e7f52d 100644 --- a/remote-curl.c +++ b/remote-curl.c @@ -1154,7 +1154,7 @@ static

[PATCH] http-push: simplify deleting a list item

oint entry->next == request and prev->next == lock, respectively.) This is a bit simpler and saves a pointer dereference. Signed-off-by: René Scharfe --- http-push.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/http-push.c b/http-push.c index 0353f9f514..822f326

[PATCH] column: use utf8_strnwidth() to strip out ANSI color escapes

erence actually doesn't matter here. Signed-off-by: René Scharfe --- column.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/column.c b/column.c index 7a17c14b82..4a38eed322 100644 --- a/column.c +++ b/column.c @@ -23,18 +23,7 @@ struct column_data { /* re

[PATCH] tests: remove "cat foo" before "test_i18ngrep bar foo"

ontents of a file that doesn't match the expected pattern, though. So don't bother doing the same unconditionally up-front. The contents are not interesting if the expected pattern is found, and showing it twice if it doesn't match is of no use. Signed-off-by: René Scharfe ---

Re: PATCH] remove duplicate #include directives

Am 06.10.19 um 01:41 schrieb Junio C Hamano: > René Scharfe writes: >> This one here requires one more piece of information, though, namely our >> convention of wrapping header files in guard defines to make repeated >> includes of them no-ops. We do that for those remo

Re: PATCH] remove duplicate #include directives

Am 04.10.19 um 01:15 schrieb Junio C Hamano: > René Scharfe writes: > >> Found with "git grep '^#include ' '*.c' | sort | uniq -d". >> >> Signed-off-by: René Scharfe >> --- >> Patch formatted with --function-context for easier rev

[PATCH] convert: fix handling of dashless UTF prefix in validate_encoding()

Strip "UTF" and an optional dash from the start of 'upper' without passing a NULL pointer to skip_prefix() in the second call, as it cannot handle that. Signed-off-by: René Scharfe --- convert.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/c

PATCH] remove duplicate #include directives

Found with "git grep '^#include ' '*.c' | sort | uniq -d". Signed-off-by: René Scharfe --- Patch formatted with --function-context for easier review. builtin/am.c | 1 - builtin/blame.c| 1 - builtin/clone.c| 1 - builtin/describe.c | 1 - bui

Re: [PATCH v2 2/8] fast-import: fix handling of deleted tags

Am 30.09.19 um 23:10 schrieb Elijah Newren: > If our input stream includes a tag which is later deleted, we were not > properly deleting it. We did have a step which would delete it, but we > left a tag in the tag list noting that it needed to be updated, and the > updating of annotated tags occur

Re: [PATCH] add a Code of Conduct document

Am 24.09.19 um 08:44 schrieb Jeff King:> +Examples of unacceptable behavior by participants include:> +> +* The use of sexualized language or imagery and unwelcome sexual attention or> + advances Sure. > +* Trolling, insulting/derogatory comments, and personal or political attacks Hmm. Trolli

Re: [PATCH 08/15] name-rev: pull out deref handling from the recursion

Am 23.09.19 um 22:47 schrieb SZEDER Gábor: > On Mon, Sep 23, 2019 at 09:55:11PM +0200, René Scharfe wrote: >> -- >8 -- >> Subject: [PATCH] name-rev: use FLEX_ARRAY for tip_name in struct rev_name >> >> Give each rev_name its very own tip_name string. This simp

Re: [PATCH 08/15] name-rev: pull out deref handling from the recursion

Am 23.09.19 um 20:59 schrieb SZEDER Gábor: > On Mon, Sep 23, 2019 at 08:43:11PM +0200, René Scharfe wrote: >>> It's overall memory usage, the avarage of five runs of: >>> >>> /usr/bin/time --format='%M' ~/src/git/git name-rev --all >>> &g

Re: [PATCH 08/15] name-rev: pull out deref handling from the recursion

Am 22.09.19 um 21:05 schrieb SZEDER Gábor: > On Sat, Sep 21, 2019 at 02:37:18PM +0200, René Scharfe wrote: >> Am 21.09.19 um 11:57 schrieb SZEDER Gábor: >>> On Fri, Sep 20, 2019 at 08:14:07PM +0200, SZEDER Gábor wrote: >>>> On Fri, Sep 20, 2019 at 08:13:02PM +0200,

Re: [PATCH 08/15] name-rev: pull out deref handling from the recursion

Am 21.09.19 um 16:21 schrieb SZEDER Gábor: > On Sat, Sep 21, 2019 at 02:37:05PM +0200, René Scharfe wrote: >> Am 20.09.19 um 20:13 schrieb SZEDER Gábor: >>>>> @@ -280,12 +269,16 @@ static int name_ref(const char *path, const struct >>>>> object_id *oid,

Re: [PATCH 08/15] name-rev: pull out deref handling from the recursion

Am 20.09.19 um 20:13 schrieb SZEDER Gábor: >>> @@ -280,12 +269,16 @@ static int name_ref(const char *path, const struct >>> object_id *oid, int flags, vo >>> if (o && o->type == OBJ_COMMIT) { >>> struct commit *commit = (struct commit *)o; >>> int from_tag = starts_with

Re: [PATCH 09/15] name-rev: restructure parsing commits and applying date cutoff

Am 19.09.19 um 23:47 schrieb SZEDER Gábor: > At the beginning of the recursive name_rev() function it parses the > commit it got as parameter, and returns early if the commit is older > than a cutoff limit. > > Restructure this so the caller parses the commit and checks its date, > and doesn't invo

Re: [PATCH 08/15] name-rev: pull out deref handling from the recursion

Am 21.09.19 um 11:57 schrieb SZEDER Gábor: > On Fri, Sep 20, 2019 at 08:14:07PM +0200, SZEDER Gábor wrote: >> On Fri, Sep 20, 2019 at 08:13:02PM +0200, SZEDER Gábor wrote: If the (re)introduced leak doesn't impact performance and memory usage too much then duplicating tip_name again in na

Re: [PATCH 03/15] name-rev: use strip_suffix() in get_rev_name()

Am 19.09.19 um 23:46 schrieb SZEDER Gábor: > Use strip_suffix() instead of open-coding it, making the code more > idiomatic. > > Signed-off-by: SZEDER Gábor > --- > builtin/name-rev.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/builtin/name-rev.c b/builtin/nam

Re: [PATCH 05/15] name-rev: use sizeof(*ptr) instead of sizeof(type) in allocation

Am 19.09.19 um 23:47 schrieb SZEDER Gábor: > Signed-off-by: SZEDER Gábor > --- > builtin/name-rev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/builtin/name-rev.c b/builtin/name-rev.c > index e406ff8e17..dec2228cc7 100644 > --- a/builtin/name-rev.c > +++ b/builtin/nam

Re: [PATCH 04/15] name-rev: avoid unnecessary cast in name_ref()

Am 19.09.19 um 23:46 schrieb SZEDER Gábor: > Casting a 'struct object' to 'struct commit' is unnecessary there, > because it's already available in the local 'commit' variable. That's true, but you can't see that only by reading your email. > > Signed-off-by: SZEDER Gábor > --- > builtin/name-r

Re: [PATCH 08/15] name-rev: pull out deref handling from the recursion

Am 19.09.19 um 23:47 schrieb SZEDER Gábor: > The 'if (deref) { ... }' condition near the beginning of the recursive > name_rev() function can only ever be true in the first invocation, > because the 'deref' parameter is always 0 in the subsequent recursive > invocations. > > Extract this condition

[PATCH] git: use COPY_ARRAY and MOVE_ARRAY in handle_alias()

transformations that introduce subtle bugs into tricky code. Signed-off-by: René Scharfe --- git.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/git.c b/git.c index c1ee7124ed..ce6ab0ece2 100644 --- a/git.c +++ b/git.c @@ -369,8 +369,7 @@ static int handle_alias(int *argcp

[PATCH] sha1_name: simplify strbuf handling in interpret_nth_prior_checkout()

Pass the target strbuf to the callback function grab_nth_branch_switch() by reference so that it can add the result string directly instead of having it put the string into a temporary strbuf first. This gets rid of an extra allocation and a string copy. Signed-off-by: René Scharfe --- Patch

[PATCH] commit-graph: use commit_list_count()

Let commit_list_count() count the number of parents instead of duplicating it. Also store the result in an unsigned int, as that's what the function returns, and the count is never negative. Signed-off-by: René Scharfe --- commit-graph.c | 17 ++--- 1 file changed, 6 inser

Re: [PATCH 2/2] sha1-name: check for overflow of N in "foo^N" and "foo~N"

Am 15.09.19 um 17:15 schrieb brian m. carlson: > This approach seems reasonable. I must admit some curiosity as to how > you discovered this issue, though. Did you have a cat assisting you in > typing revisions? Found it by reading the code, but I'm not sure anymore what I was actually looking f

[PATCH 2/2] sha1-name: check for overflow of N in "foo^N" and "foo~N"

erflow. Signed-off-by: René Scharfe --- sha1-name.c| 15 --- t/t1506-rev-parse-diagnosis.sh | 4 ++-- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/sha1-name.c b/sha1-name.c index c665e3f96d..7a047e9e2b 100644 --- a/sha1-name.c +++ b/sha1-nam

[PATCH 1/2] rev-parse: demonstrate overflow of N for "foo^N" and "foo~N"

s. Signed-off-by: René Scharfe --- t/t1506-rev-parse-diagnosis.sh | 8 1 file changed, 8 insertions(+) diff --git a/t/t1506-rev-parse-diagnosis.sh b/t/t1506-rev-parse-diagnosis.sh index 4ee009da66..5c4df47401 100755 --- a/t/t1506-rev-parse-diagnosis.sh +++ b/t/t1506-rev-parse-di

[PATCH 1/2] log: test --decorate-refs-exclude with --simplify-by-decoration

Demonstrate that a decoration filter given with --decorate-refs-exclude is inadvertently overruled by --simplify-by-decoration. Reported-by: Étienne SERVAIS Signed-off-by: René Scharfe --- t/t4202-log.sh | 15 +++ 1 file changed, 15 insertions(+) diff --git a/t/t4202-log.sh b/t

[PATCH 2/2] log-tree: call load_ref_decorations() in get_name_decoration()

-off-by: René Scharfe --- log-tree.c | 1 + pretty.c | 2 -- revision.c | 1 - t/t4202-log.sh | 2 +- 4 files changed, 2 insertions(+), 4 deletions(-) diff --git a/log-tree.c b/log-tree.c index 1e56df62a7..2d5710e707 100644 --- a/log-tree.c +++ b/log-tree.c @@ -77,6 +77,7 @@ void

Re: [PATCH 1/2] tag: factor out get_tagged_oid()

Am 06.09.19 um 17:05 schrieb René Scharfe: > A tag referencing an unknown object sounds strange to me. I imagine we > might get such a thing when the referenced object is lost (broken repo) > or purpose-built from an attacker. Could such a tag still be used for > anything? Are

Re: [PATCH 1/2] tag: factor out get_tagged_oid()

Am 06.09.19 um 09:13 schrieb Jeff King: > On Thu, Sep 05, 2019 at 09:55:55PM +0200, René Scharfe wrote: > >> Add a function for accessing the ID of the object referenced by a tag >> safely, i.e. without causing a segfault when encountering a broken tag >> where ->tagged

[PATCH 2/2] use get_tagged_oid()

Avoid derefencing ->tagged without checking for NULL by using the convenience wrapper for getting the ID of the tagged object. It die()s when encountering a broken tag instead of segfaulting. Signed-off-by: René Scharfe --- builtin/describe.c | 2 +- builtin/log.c | 5 +++-- buil

[PATCH 1/2] tag: factor out get_tagged_oid()

Add a function for accessing the ID of the object referenced by a tag safely, i.e. without causing a segfault when encountering a broken tag where ->tagged is NULL. Signed-off-by: René Scharfe --- pack-bitmap.c | 4 +--- revision.c| 4 +--- tag.c | 7 +++ tag.h | 1 +

Re: [PATCH] Fix maybe-uninitialized warnings found by gcc 9 -flto

Am 05.09.19 um 21:25 schrieb Junio C Hamano: > René Scharfe writes: > >> Am 05.09.19 um 19:53 schrieb Jeff King: >>>>> int cmd__read_cache(int argc, const char **argv) >>>>> { >>>>> - int i, cnt = 1, namelen; >>>>>

Re: [PATCH] Fix maybe-uninitialized warnings found by gcc 9 -flto

Am 05.09.19 um 19:53 schrieb Jeff King: >>> int cmd__read_cache(int argc, const char **argv) >>> { >>> - int i, cnt = 1, namelen; >>> + int i, cnt = 1, namelen = 0; > > I actually saw this one the other day, because it triggered for me when > compiling with SANITIZE=address. AFAICT it's

Re: [PATCH] Fix maybe-uninitialized warnings found by gcc 9 -flto

Am 05.09.19 um 10:24 schrieb Stephan Beyer: > Compiler heuristics for detection of potentially uninitialized variables > may change between compiler versions and enabling link-time optimization > may find new warnings. Indeed, compiling with gcc 9.2.1 and enabled > link-time optimization feature r

Re: [PATCH] help: make help_unknown_ref() NORETURN

Am 29.08.19 um 21:40 schrieb Martin Ågren: > On Thu, 29 Aug 2019 at 21:15, René Scharfe wrote: >> diff --git a/help.h b/help.h >> index b8780fbd0f..7a455beeb7 100644 >> --- a/help.h >> +++ b/help.h >> @@ -42,8 +42,8 @@ void list_commands(unsigned int colopt

[PATCH] help: make help_unknown_ref() NORETURN

Announce that calling help_unknown_ref() exits the program. Signed-off-by: René Scharfe --- Patch generated with --function-context for easier review. help.c | 3 ++- help.h | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/help.c b/help.c index 5261d83ecf..9ff2be6b18

Re: [PATCH] fix segv with corrupt tag object

ee_indirect() Reduce code duplication by turning parse_tree_indirect() into a wrapper of repo_peel_to_type(). This avoids a segfault when handling a broken tag where ->tagged is NULL. The new version also checks the return value of parse_object() that was ignored by the old one. Initial-

[PATCH] trace2: use warning() directly in tr2_dst_malformed_warning()

Let warning() format the message instead of using an intermediate strbuf for that. This is shorter, easier to read and avoids an allocation. Signed-off-by: René Scharfe --- trace2/tr2_dst.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/trace2/tr2_dst.c b/trace2

Re: [PATCH 2/2] fast-import: duplicate into history rather than passing ownership

Am 25.08.19 um 12:02 schrieb Mike Hommey: > On Sun, Aug 25, 2019 at 04:10:55AM -0400, Jeff King wrote: >> diff --git a/fast-import.c b/fast-import.c >> index ee7258037a..1f9160b645 100644 >> --- a/fast-import.c >> +++ b/fast-import.c >> @@ -1763,7 +1763,6 @@ static int read_next_command(void) >>

[PATCH] grep: use return value of strbuf_detach()

standard sequence anyway for consistency. Signed-off-by: René Scharfe --- builtin/grep.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/builtin/grep.c b/builtin/grep.c index 2699001fbd..69ac053acc 100644 --- a/builtin/grep.c +++ b/builtin/grep.c @@ -1110,8 +1110,8 @@ int

[PATCH] log-tree: always use return value of strbuf_detach()

strbuf_detach() has been returning a pointer to a buffer even for empty strbufs since 08ad56f3f0 ("strbuf: always return a non-NULL value from strbuf_detach", 2012-10-18). Use that feature in show_log() instead of having it handle empty strbufs specially. Signed-off-by: René Scharf

Re: [PATCH] fast-import: Reinitialize command_buf rather than detach it.

Am 25.08.19 um 06:13 schrieb Mike Hommey: > command_buf.buf is also stored in cmd_hist, so instead of > strbuf_release, the current code uses strbuf_detach in order to > "leak" the buffer as far as the strbuf is concerned. Hmm. > However, strbuf_detach does more than "leak" the strbuf buffer: it

Re: [PATCH] fix segv with corrupt tag object

Am 25.08.19 um 01:09 schrieb Stefan Sperling: > A tag object which lacks newlines won't be parsed correctly. > Git fails to detect this error and crashes due to a NULL deref: > > $ git archive 1.0.0 > Segmentation fault (core dumped) > $ git checkout 1.0.0 > Segmentation fault (core dumped) > $ Go

Re: [BUG] You can't have single quote in your username

Am 22.08.19 um 14:32 schrieb Giuseppe Crinò: > name = Les Actualite\\' You can name yourself anything you like, of course, and I don't actually speak French, but wouldn't it rather be "L'actualité"? I just reply as a fellow accent-bearer, feel free to ignore me.. René

Re: [PATCH 02/26] patch-id: convert to use the_hash_algo

reordering", 2014-04-27), and there is no need for a private copy of the second hexadecimal hash value since dcb3450fd8 ("sha1_to_hex() usage cleanup", 2006-05-03) added support for up to four sha1_to_hex() results to be used in the same printf(3) call, which oid_to_hex() inherite

[PATCH] sha1-name: make sort_ambiguous_oid_array() thread-safe

Use QSORT_S instead of QSORT, which allows passing the repository pointer to the comparison function without using a static variable. Signed-off-by: René Scharfe --- sha1-name.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/sha1-name.c b/sha1-name.c index

[PATCH] parseopt: move definition of enum parse_opt_result up

ctx_t *ctx, ^ While GCC and Clang both accept such a forward reference by default, other compilers might be less forgiving. Signed-off-by: René Scharfe --- parse-options.h | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/parse-options.h b/parse-optio

[PATCH 4/4] archive-tar: turn length miscalculation warning into BUG

Now that we're confident our pax extended header calculation is correct, turn the criticality of the assertion up to the maximum, from warning right up to BUG. Simplify the test, as the stderr comparison step would not be reached in case the BUG message is triggered. Signed-off-by: René Sc

[PATCH 3/4] archive-tar: use size_t in strbuf_append_ext_header()

One of its callers already passes in a size_t value. Use it consistently in this function. Signed-off-by: René Scharfe --- archive-tar.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/archive-tar.c b/archive-tar.c index 4395a29ffb..9d09edd547 100644 --- a

[PATCH 2/4] archive-tar: fix pax extended header length calculation

ot;, 2006-03-25). Account for digits added to len during the loop and keep incrementing until we have enough space for len and the rest. The crucial change is to check against the current value of len before each iteration, instead of against its value before the loop. Signed-off-by: René Scharfe ---

[PATCH 1/4] archive-tar: report wrong pax extended header length

Extended header entries contain a length value that is a bit tricky to calculate because it includes its own length (number of decimal digits) as well. We get it wrong in corner cases. Add a check, report wrong results as a warning and add a test for exercising it. Signed-off-by: René Scharfe

[PATCH 0/4] fix pax extended header length calculation

The code for building pax extended headers has been miscalculating lengths slightly shorter than powers of 10 since I wrote it in 2006. That affects entries for paths with a length of 990, 991, 9989, 9990, 9991, 99988 etc. and link targets 4 characters shorter. Here's a series for fixing it. a

Re: [PATCH v2] unpack-trees.c: distinguish ita files from empty files

Am 15.08.19 um 18:21 schrieb Varun Naik: > diff --git a/unpack-trees.c b/unpack-trees.c > index 50189909b8..5e6d88f36b 100644 > --- a/unpack-trees.c > +++ b/unpack-trees.c > @@ -1658,9 +1658,10 @@ static int same(const struct cache_entry *a, const > struct cache_entry *b) > return 0;

Re: [RFC PATCH] unpack-trees.c: handle empty deleted ita files

Am 13.08.19 um 22:32 schrieb Junio C Hamano: > So perhaps > > + !ce_intent_to_add(a) && !ce_intent_to_add(b) && > > i.e. "a cache entry is eligible to be same with something else only > when its I-T-A bit is unset". FWIW, here's another way to express that: diff --git a/unpack-trees.c b/unpac

Re: [RFC PATCH] unpack-trees.c: handle empty deleted ita files

Am 13.08.19 um 18:03 schrieb Varun Naik: > It is possible to delete a committed file from the index and then add it > as intent-to-add. Several variations of "reset" and "checkout" should > resurrect the file in the index from HEAD. "merge", "cherry-pick", and > "revert" should all fail with an err

Re: [PATCH] SQUASH

Am 12.08.19 um 09:35 schrieb Carlo Arenas: > On Sat, Aug 10, 2019 at 12:48 PM René Scharfe wrote: >>> On Sat, Aug 10, 2019 at 12:57 AM René Scharfe wrote: >>> >>> Do you mind then if I "adopt" your patch and submit a reroll with it, >> >> I

Re: [RFC PATCH v5 0/3] grep: almost no more leaks, hopefully no crashes

Am 10.08.19 um 14:40 schrieb Carlo Arenas: > On Sat, Aug 10, 2019 at 12:57 AM René Scharfe wrote: >> I don't understand why my performance is lower by factor 2.5 than yours >> for all perl regex tests except 7820.15 (your 7820.4), where my system >> is two times faster.

Re: [PATCH] SQUASH

Am 10.08.19 um 10:42 schrieb Carlo Arenas: > On Sat, Aug 10, 2019 at 12:57 AM René Scharfe wrote: >> >> Am 10.08.19 um 05:03 schrieb Carlo Marcelo Arenas Belón: >>> Make using a general context (that is only needed with NED) to depend >>> on NED being selecte

Re: [PATCH] SQUASH

Am 10.08.19 um 05:03 schrieb Carlo Marcelo Arenas Belón: > Make using a general context (that is only needed with NED) to depend > on NED being selected at compile time. A custom general context is needed to convince PCRE2 to use xmalloc() instead of mallo(). That is independent of the choice of

Re: [RFC PATCH v5 0/3] grep: almost no more leaks, hopefully no crashes

Am 10.08.19 um 05:05 schrieb Carlo Arenas: > in macOS (obviously testing without NED) the following is the output > of (a hacked version) of p7801 for maint (against chromium's > repository), with René's patch on top Do you mean p7820? And what did you change? Looking at the results you removed

Re: [PATCH v2 5/7] quote: add sq_quote_argv_pretty_ltrim

Am 09.08.19 um 19:13 schrieb Jeff Hostetler: > On 8/8/2019 6:49 PM, René Scharfe wrote: >>   void sq_quote_argv_pretty(struct strbuf *dst, const char **argv) >>   { >> -    int i; >> - >> -    for (i = 0; argv[i]; i++) { >> -    strbuf_addch(dst, ' &

Re: [RFC PATCH v5 0/3] grep: almost no more leaks, hopefully no crashes

) for all PCRE2 allocations Build a PCRE2 global custom context when compiling a pattern and use it to tell the library to use xmalloc() for allocations. This provides consistent out-of-memory handling and makes sure it uses a custom allocator, e.g. with USE_NED_ALLOCATOR. Signed-off-by: René Scharfe

Re: [PATCH v2 5/7] quote: add sq_quote_argv_pretty_ltrim

Am 08.08.19 um 21:04 schrieb Jeff Hostetler: > On 8/8/2019 2:05 PM, Junio C Hamano wrote: >> Having made the primary purpose of the helper clearer leads me to >> wonder if "do not add SP before the first element, i.e. argv[0]", is >> really what we want.  If we always clear the *dst strbuf before >

Re: [RFC PATCH v3 2/3] grep: make PCRE2 aware of custom allocator

Am 08.08.19 um 14:38 schrieb Carlo Arenas: > On Thu, Aug 8, 2019 at 12:07 AM René Scharfe wrote: >> >> Am 08.08.19 um 04:35 schrieb Carlo Arenas: >>> On Wed, Aug 7, 2019 at 6:03 AM René Scharfe wrote: >>>> >>>> Am 07.08.19 um 11:49 schrieb Carlo

Re: [RFC PATCH v3 2/3] grep: make PCRE2 aware of custom allocator

Am 08.08.19 um 04:35 schrieb Carlo Arenas: > On Wed, Aug 7, 2019 at 6:03 AM René Scharfe wrote: >> >> Am 07.08.19 um 11:49 schrieb Carlo Arenas: >>> was hoping will perform better but it seems that testing can be done >>> only in windows >> >> nedm

[PATCH 2/2] nedmalloc: avoid compiler warning about unused value

on of macro ‘INITIAL_LOCK’ 5020 | INITIAL_LOCK(&m->mutex); | ^~~~ Signed-off-by: René Scharfe --- compat/nedmalloc/malloc.c.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h index 88c131ca93

[PATCH 1/2] nedmalloc: do assignments only after the declaration section

| volatile unsigned int* lp = &sl->l; | ^~~~ Signed_off-by: René Scharfe --- compat/nedmalloc/malloc.c.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h index b833ff9225..88c131ca93 100644 --- a

Re: [RFC PATCH v3 2/3] grep: make PCRE2 aware of custom allocator

Am 07.08.19 um 11:49 schrieb Carlo Arenas: > was hoping will perform better but it seems that testing can be done > only in windows nedmalloc works on other platforms as well. On Debian Testing with GCC 9.1.0 I need two changes to suppress some compiler warnings, though. Will post them as replies

[PATCH] dir-iterator: release strbuf after use

Signed-off-by: René Scharfe --- Patch generated with --function-context for easier review. The plugged leak was added after v2.22.0 (2019-06-07) by 3012397e03 (dir-iterator: refactor state machine model, 2019-07-10). refs/files-backend.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion

[PATCH] sha1-file: release strbuf after use

Signed-off-by: René Scharfe --- Patch generated with --function-context for easier review. The plugged leak was added by a10a17877b (for_each_alternate_ref: replace transport code with for-each-ref, 2017-02-08) and showed up in 709dfa6990 (object-store.h: move for_each_alternate_ref() from

[PATCH] test-dir-iterator: use path argument directly

Avoid allocating and leaking a strbuf for holding a verbatim copy of the path argument and pass the latter directly to dir_iterator_begin() instead. Signed-off-by: René Scharfe --- This test helper was added after v2.22.0 (2019-06-07) by 150791adbf (dir-iterator: add tests for dir-iterator API

[PATCH] commit-graph: release strbufs after use

Signed-off-by: René Scharfe --- Patch generated with --function-context for easier review. That makes it look a lot bigger than it actually is, though. The plugged leaks were added after v2.22.0 (2019-06-07) by the following commits: 5c84b3396c 2019-06-18 commit-graph: load commit-graph chains

Re: [RFC PATCH v3 2/3] grep: make PCRE2 aware of custom allocator

Am 06.08.19 um 18:36 schrieb Carlo Marcelo Arenas Belón: > 94da9193a6 (grep: add support for PCRE v2, 2017-06-01) didn't include > a way to override the system allocator, and so it is incompatible with > USE_NED_ALLOCATOR. The problem was made visible when an attempt to > avoid a leak in a data st

Re: Simplify-by-decoration with decorate-refs-exclude

Am 02.08.19 um 23:20 schrieb Junio C Hamano: > René Scharfe writes: > >> Having cmd_log_init_finish() call load_ref_decorations() before >> setup_revisions() would indeed solve the issue as well. But we need >> to call the latter to check if --pretty=raw was

Re: Simplify-by-decoration with decorate-refs-exclude

Am 02.08.19 um 21:14 schrieb Junio C Hamano: > I can see how this would help, but it somehow feels a bit brittle > to rely on where the decorations get loaded. Right. > I wonder if it would help to move the ability to handle decoration > filter down from the log layer to revisions.c API layer. >

Re: Simplify-by-decoration with decorate-refs-exclude

sion option --simplify-by-decoration together with the log option --decorate-refs-exclude and having it simplify over the restricted set of refs. Reported-by: Étienne SERVAIS Signed-off-by: René Scharfe --- revision.c | 8 +++- t/t4202-log.sh | 15 +++ 2 files changed, 22 inserti

Re: Support for --stdin-paths in commit, add, etc

Am 31.07.19 um 17:45 schrieb Alexandr Miloslavskiy: > Our suggestion is to change commands such as 'commit', 'add', etc to > also work with --stdin-paths. If a command already supports stdin for > any purpose, then trying to use both options will return an error. Would it make sense to have a --pa

Re: [ANNOUNCE] Git v2.23.0-rc0 - Initial test failures on NonStop

Am 31.07.19 um 05:27 schrieb Jeff King: > One thing that makes it all a bit funky is that the "put" lines also > output the old value (which is what all those NULLs) are. And I think > that solves my "value3" puzzlement from earlier. It is not part of the > iteration at all, but rather the result o

Re: [RFC PATCH v2] grep: allow for run time disabling of JIT in PCRE

Am 30.07.19 um 02:49 schrieb Carlo Arenas: > On Mon, Jul 29, 2019 at 10:47 AM Junio C Hamano wrote: >> René Scharfe writes: >>>> +pcre.jit:: >>>> +If set to false, disable JIT when using PCRE. Defaults to >>>> +true. >>>> +i

Re: [PATCH 3/3] grep: plug leak of pcre chartables in PCRE2

Am 30.07.19 um 02:08 schrieb Carlo Arenas: > On Mon, Jul 29, 2019 at 1:35 PM René Scharfe wrote: >> >> Am 28.07.19 um 03:41 schrieb Carlo Arenas: >>> On Sat, Jul 27, 2019 at 4:48 PM Ævar Arnfjörð Bjarmason >>> wrote: >>>>> + free((void *)p-&g

Re: [PATCH 3/3] grep: plug leak of pcre chartables in PCRE2

Am 28.07.19 um 03:41 schrieb Carlo Arenas: > On Sat, Jul 27, 2019 at 4:48 PM Ævar Arnfjörð Bjarmason > wrote: >>> + free((void *)p->pcre_tables); >> >> Is the cast really needed? I'm rusty on the rules, removing it from the >> pcre_free() you might have copied this from produces a warning for

Re: [RFC PATCH v2] grep: allow for run time disabling of JIT in PCRE

Am 29.07.19 um 12:59 schrieb Carlo Marcelo Arenas Belón: > PCRE1 allowed for a compile time flag to disable JIT, but PCRE2 never > had one, forcing the use of JIT if -P was requested. > > After ed0479ce3d (Merge branch 'ab/no-kwset' into next, 2019-07-15) > the PCRE2 engine will be used more broadl

Re: [PATCH] archive: Store checksum correctly

Am 23.07.19 um 21:38 schrieb René Scharfe: > is_checksum_valid() in > https://github.com/AgentD/squashfs-tools-ng/blob/master/lib/tar/checksum.c > compares the formatted checksum byte-by-byte. That seems > unnecessarily strict. Parsing and comparing the numerical value > of the ch

Re: [PATCH] archive: Store checksum correctly

Am 23.07.19 um 18:49 schrieb Junio C Hamano: > Matt Turner writes: > >> tar2sqfs (part of https://github.com/topics/tar2sqfs) rejects tarballs >> made with git archive with the message >> >> invalid tar header checksum! >> >> tar2sqfs recomputes the tarball's checksum to verify it. Its checksu

Re: [PATCH 1/1] clean: show an error message when the path is too long

Am 16.07.19 um 16:04 schrieb Johannes Schindelin via GitGitGadget: > From: Johannes Schindelin > > Without an error message when stat() failed, e.g. `git clean` would > abort without an error message, leaving the user quite puzzled. > > In particular on Windows, where the default maximum path leng

Re: [PATCH 2/3] sequencer: factor out todo command name parsing

Am 25.06.19 um 12:11 schrieb Phillip Wood via GitGitGadget: > From: Phillip Wood > > Factor out the code that parses the name of the command at the start of > each line in the todo file into it's own function so that it can be used > in the next commit. "Factor out" sounds like functionality is i

Re: [PATCH 15/17] khash: rename oid helper functions

Am 20.06.19 um 20:27 schrieb Jeff King: > On Thu, Jun 20, 2019 at 10:44:17AM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >>> For use in object_id hash tables, we have oid_hash() and oid_equal(). >>> But these are confusingly similar to the existing oideq() and the >>> oidhash() we plan

[PATCH v2 3/3] config: simplify parsing of unit factors

Just return the value of the factor or zero for unrecognized strings instead of using an output reference and a separate return value to indicate success. This is shorter and simpler. It basically reverts that function to before c8deb5a146 ("Improve error messages when int/long cannot be parsed f

[PATCH v2 2/3] config: don't multiply in parse_unit_factor()

parse_unit_factor() multiplies the number that is passed to it with the value of a recognized unit factor (K, M or G for 2^10, 2^20 and 2^30, respectively). All callers pass in 1 as a number, though, which allows them to check the actual multiplication for overflow before they are doing it themsel

Re: [PATCH 4/4] config: avoid calling `labs()` on too-large data type

Am 21.06.19 um 20:35 schrieb Johannes Schindelin: > Hi René, > > On Thu, 20 Jun 2019, René Scharfe wrote: > >> Subject: [PATCH] config: simplify unit suffix handling >> >> parse_unit_factor() checks if a K, M or G is present after a number and >> multiplies it

[PATCH v2 1/3] config: use unsigned_mult_overflows to check for overflows

parse_unit_factor() checks if a K, M or G is present after a number and multiplies it by 2^10, 2^20 or 2^30, respectively. One of its callers checks if the result is smaller than the number alone to detect overflows. The other one passes 1 as the number and does multiplication and overflow check

Re: [PATCH 4/4] config: avoid calling `labs()` on too-large data type

Am 17.06.19 um 00:26 schrieb Junio C Hamano: > René Scharfe writes: > >>>>> To fix it, let's just "unroll" the function (i.e. negate the value if it >>>>> is negative). >>>> >>>> There's also imaxabs(3). > > T

Re: [PATCH 4/4] config: avoid calling `labs()` on too-large data type

Am 16.06.19 um 10:24 schrieb René Scharfe: > Am 16.06.19 um 08:48 schrieb René Scharfe: >> Am 13.06.19 um 13:49 schrieb Johannes Schindelin via GitGitGadget: >>> From: Johannes Schindelin >>> >>> The `labs()` function operates, as the initial `l` suggests, o

Re: [PATCH 4/4] config: avoid calling `labs()` on too-large data type

Am 16.06.19 um 08:48 schrieb René Scharfe: > Am 13.06.19 um 13:49 schrieb Johannes Schindelin via GitGitGadget: >> From: Johannes Schindelin >> >> The `labs()` function operates, as the initial `l` suggests, on `long` >> parameters. However, in `config.c` we tried

Re: [PATCH 4/4] config: avoid calling `labs()` on too-large data type

Am 13.06.19 um 13:49 schrieb Johannes Schindelin via GitGitGadget: > From: Johannes Schindelin > > The `labs()` function operates, as the initial `l` suggests, on `long` > parameters. However, in `config.c` we tried to use it on values of type > `intmax_t`. > > This problem was found by GCC v9.x.

[PATCH 2/2] use COPY_ARRAY for copying arrays

Convert calls of memcpy(3) to use COPY_ARRAY, which shortens and simplifies the code a bit. Patch generated by Coccinelle and contrib/coccinelle/array.cocci. Signed-off-by: Rene Scharfe --- fast-import.c | 2 +- kwset.c | 2 +- packfile.c| 6 +++--- pretty.c | 4 ++-- 4 files cha

[PATCH 1/2] coccinelle: use COPY_ARRAY for copying arrays

The current semantic patch for COPY_ARRAY transforms memcpy(3) calls on pointers, but Coccinelle distinguishes them from arrays. It already contains three rules to handle the options for sizeof (i.e. source, destination and type), and handling arrays as source and destination would require four ti

  1   2   3   4   5   6   7   8   9   10   >