On Sun, Dec 9, 2018 at 4:42 PM brian m. carlson
wrote:
>
> On Mon, Dec 10, 2018 at 12:51:01AM +0100, Ævar Arnfjörð Bjarmason wrote:
> > Obviously this & what you have in 2/2 needs to be fixed in some way.
> >
> > Is the issue on SELinux, OpenBSD, NetBSD etc. *how* PCRE is creating the
> > the JIT'
On Mon, Dec 10, 2018 at 12:24 AM Ævar Arnfjörð Bjarmason
wrote:
> On Mon, Dec 10 2018, brian m. carlson wrote:
> > Considering that some Linux users use PaX kernels with standard
> > distributions and that most BSD kernels can be custom-compiled with a
> > variety of options enabled or disabled, I
On Tue, Dec 18, 2018 at 7:29 PM John Passaro wrote:
>
> I recently submitted my first patch using OSX and found the experience
> frustrating, for reasons that have come up on the list before,
> concerning git-send-email and perl dependencies that you need to be
> root to update.
you can install t
On Fri, Dec 21, 2018 at 8:34 AM Johannes Schindelin via GitGitGadget
wrote:
> +test_expect_success MINGW 'path is case-insensitive' '
CASE_INSENSITIVE_FS might be a better prereq
Carlo
slightly offtopic and definitely not meant to be relevant as a critic
on this specific change which I found otherwise fine, but just a heads
up that this test itself is bash specific (since it uses arrays,
against the recommendation in Documentation/CodingGuidelines) and
therefore breaks, at least
Tested-By: Carlo Marcelo Arenas Belón
one important point to consider when tracking this bug is that perl is
not crashing, but is told to abort by some instrumentation (most
likely gcc's fortify) and as shown by :
*** buffer overflow detected ***: /usr/bin/perl terminated
Carlo
v2 works fine, as expected
Carlo
while running HEAD cppcheck against git HEAD got the following error,
that seem to be in the code all the way to maint:
[refs/files-backend.c:2681] -> [refs.c:1044] -> [cache.h:1075]:
(error) Null pointer dereference: src
the code that uses NULL as the source OID was introduced with
b0ca411051 ("
/usr/local/versioner/perl/versions is also not provided with macOS or
Xcode AFAIK
Carlo
On Wed, Jan 30, 2019 at 4:30 AM Jeff Hostetler wrote:
> BTW, how do you find these? I ran both "make sparse" and
> "make DEVELOPER=1" and it didn't complain about these items.
$ make hdr-check
available since ebb7baf02f ("Makefile: add a hdr-check target", 2018-09-19)
Carlo
> It seems most packagers build with PCRE v2 now (CC:
> git-packagers@). I.e. we'd keep something like compile_fixed_regexp()
> (and as an aside just use PCRE's \Q...\E instead of our own escaping).
OpenBSD does PCRE v1 without JIT but HardenedBSD does and therefore
segfaults when calling: `git gr
On Sun, Jun 16, 2019 at 6:17 PM Derrick Stolee wrote:
>
> Thanks for catching this. I wonder if there is a compiler setting or
> static analysis that caught this so we can avoid the issue in the future.
-Wsign-compare would definitely raise a warning about this, but we have
currently 956 of those
shouldn't this also be a problem with builtin/blame.c?
Carlo
On Tue, Jun 18, 2019 at 5:26 AM Jeff Hostetler via GitGitGadget
wrote:
> diff --git a/compat/mingw.c b/compat/mingw.c
> index d14d33308d..667285887a 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -2388,6 +2388,12 @@ static void maybe_redirect_std_handles(void)
>
On Tue, Jun 18, 2019 at 8:53 AM Jeff King wrote:
>
> Thanks, this looks good to me. I fixed the system headers in xinclude.h,
> but didn't think to check for individual C files including them.
also noticed that after the refactoring some files will include a couple
of headers twice (not an issue,
while those two changes (from DEBUG to DEBUG_$foo) are worth doing in
their own merit, I am more inclined to consider this as orthogonal
since by your own description[1] the right name to use would be _DEBUG
(with a preceding dash) and that would obviously not conflict here.
the only remaining cha
On Fri, Jun 28, 2019 at 6:44 PM Derrick Stolee wrote:
>
> On 6/28/2019 5:42 PM, Junio C Hamano wrote:
> > "Derrick Stolee via GitGitGadget" writes:
> >
> > Use of "signed char" would be OK, but this is a singleton instance
> > per repository, so I am not sure how much it matters to save a few
> >
On Mon, Jul 1, 2019 at 8:32 AM Derrick Stolee via GitGitGadget
wrote:
>
> To centralize these config options and properly set the defaults,
> create a repo_settings that contains chars for each config variable.
> Use -1 as "unset", with 0 for false and 1 for true.
minor nitpick that hopefully Jun
On Wed, Jul 3, 2019 at 11:49 AM Junio C Hamano wrote:
>
> Carlo, no need to rush, but has this happened already? I do not
> recall seeing an update, and I am wondering if I missed one.
Junio; had yet to send the update, so nothing was missed
Carlo
On Sat, Jul 13, 2019 at 3:46 AM Johannes Sixt wrote:
>
> Using only = { 0 } for zero-initialization makes the code immune to
> rearrangements of the struct members.
But only by forcing to set whichever is the first element to 0, which is
exactly what sparse is complaining about, since it happens
On Sat, Jul 13, 2019 at 2:29 PM Junio C Hamano wrote:
>
> I wish if we could say
>
> struct patch patch = {};
that is actually a GNU extension that is supported by gcc and clang (at least)
and that sparse also recognizes as valid; it is also valid C++ so it might be
even supported by MSVC
On Tue, Jul 9, 2019 at 2:16 PM Emily Shaffer wrote:
>
> diff --git a/transport.c b/transport.c
> index f1fcd2c4b0..d768bc275e 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -1226,6 +1226,19 @@ int transport_push(struct repository *r,
> err = push_had_errors(remote_refs);
>
On Tue, Jul 16, 2019 at 9:54 AM Junio C Hamano wrote:
>
> Does everything else compile OK with your rather old compiler on
> Centos 6?
yes, they were a few -Wmaybe-uninitialized warnings but they were most
likely false positives.
gcc 4.4.7 aborts the build (even without -Werror) with the followi
On Thu, Jul 18, 2019 at 6:31 PM Jonathan Nieder wrote:
>
> This makes sense to me. Not really for the 'for' loop declaration
> aspect: for that, I'd want some more specialized tool that allows
> turning on such a check specifically. But more because Ubuntu trusty
> is still a platform that some
On Mon, Jul 22, 2019 at 12:42 PM Ævar Arnfjörð Bjarmason
wrote:
>
> On Mon, Jul 22 2019, Johannes Schindelin wrote:
>
> > So I am fine with this patch.
>
> I'm not, not because I dislike the approach. I haven't made up my mind
> yet.
my bad, I should had explained better the regression I was tryi
On Tue, Jul 23, 2019 at 5:47 AM Johannes Schindelin
wrote:
>
> So when PCRE2 complains about the top two bits not being 0x80, it fails
> to parse the bytes correctly (byte 2 is 0xbb, whose two top bits are
> indeed 0x80).
the error is confusing but it is not coming from the pattern, but from
what
On Wed, Jul 24, 2019 at 1:20 PM Ævar Arnfjörð Bjarmason
wrote:
> On Wed, Jul 24 2019, Junio C Hamano wrote:
> >
> > Does everybody use pcre2 with JIT with Git these days, or only those
> > who want to live near the bleeding edge?
>
> My informal survey of various package recipies suggests that all
since this moves PCRE1 out of the JIT fast path, introduces the
regression where git grep will abort if there is binary data or non
UTF-8 text in the repository/log and should be IMHO hold out until a
fix for that can be merged.
this also needs additional changes to better support NO_LIBPCRE1_JIT,
On Fri, Jul 26, 2019 at 6:50 AM Ævar Arnfjörð Bjarmason
wrote:
>
> On Fri, Jul 26 2019, Carlo Arenas wrote:
>
> > since this moves PCRE1 out of the JIT fast path,
>
> I think you're mostly replying to the wrong thread. None of the patches
> I've sent disab
On Fri, Jul 26, 2019 at 8:15 AM Ævar Arnfjörð Bjarmason
wrote:
> I'm not sure what a real fix for that is. Part of it is probably 8/8 in
> the series I mention below, but more generally we'd need to be more
> encoding aware at a much higher callsite than "grep". So e.g. we'd know
> that we match "
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 me,
> but not for free() itself. This is on GCC 8.
On Sat, Jul 27, 2019 at 4:47 PM Ævar Arnfjörð Bjarmason
wrote:
>
> On Sat, Jul 27 2019, Carlo Marcelo Arenas Belón wrote:
>
> > 6d4b5747f0 ("grep: change internal *pcre* variable & function names
> > to be *pcre1*", 2017-05-25), renamed most variables to be PCRE1
> > specific to give space to simi
On Thu, Jul 25, 2019 at 5:19 PM Junio C Hamano wrote:
> [Stalled]
>
> * cb/xdiff-no-system-includes-in-dot-c (2019-06-19) 1 commit
> - xdiff: avoid accidental redefinition of LFS feature in OpenIndiana
>
> Compilation fix.
>
> Will be rerolled together with patches from the
> jk/no-system-incl
On Sun, Jul 28, 2019 at 4:54 PM Carlo Marcelo Arenas Belón
wrote:
> @@ -125,6 +126,12 @@ int grep_config(const char *var, const char *value, void
> *cb)
> return 0;
> }
>
> + if (!strcmp(var, "pcre.jit")) {
> + int is_bool;
> + opt->pcre_j
On Fri, Jul 26, 2019 at 8:08 AM Ævar Arnfjörð Bjarmason
wrote:
>
> As noted in [3] there are known regexes that will fail with the lower
> stack limit, the way GNU grep fixed it is interesting, although I
> believe the implementation is overly verbose, they could make PCRE v2
> handle that gradual
On Fri, Jul 26, 2019 at 8:09 AM Ævar Arnfjörð Bjarmason
wrote:
>
> It will also implicitly re-enable UTF-8 validation for PCRE v1. As
> noted in [1] we now have cases as a result where PCRE v1 is more eager
> to error out. Subsequent patches will fix that for v2, and I think
> it's fair to tell v1
On Fri, Jul 26, 2019 at 8:09 AM Ævar Arnfjörð Bjarmason
wrote:
>
> It's less confusing to use that variable consistently that switch back
> & forth between the two.
>
> Signed-off-by: Ævar Arnfjörð Bjarmason
> ---
> grep.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/
On Fri, Jul 26, 2019 at 8:09 AM Ævar Arnfjörð Bjarmason
wrote:
>
> This patch does nothing to fix that, instead we sneak in support for
> fixed patterns starting with "(*NO_JIT)", this disables the PCRE v2
> jit with implicit fixed-string matching for testing, see
> pcre2syntax(3) the syntax.
Alt
On Sun, Jul 28, 2019 at 9:57 PM Junio C Hamano wrote:
>
> I am not sure I like a config-only knob like this,
> though---shouldn't we have a command line knob to turn jit off
> first, and then for those who gets tired of having to type it all
> the time add the configuration to flip the default for
On Thu, Jul 25, 2019 at 5:50 AM Johannes Schindelin
wrote:
> On Wed, 24 Jul 2019, Beat Bolli wrote:
> > Do you mean something like this?
>
> Yes!
Ideally, though, you want to print those values closing to the match
function (pcre_exec for PCRE1
or pcre2_[jit_]match for PCRE2 as they might change
On Mon, Jul 29, 2019 at 1:55 AM Ævar Arnfjörð Bjarmason
wrote:
>
> On Mon, Jul 29 2019, Carlo Marcelo Arenas Belón wrote:
>
> > PCRE1 allowed for a compile time flag to disable JIT, but PCRE2 never
> > had one, forcing the use of JIT if -P was requested.
>
> What's that PCRE1 compile-time flag?
N
Known Issues:
* PCRE1 is broken, but fixing it would make more sense on top of the
topic[1] (not in pu)
* it depends on the current ab/pcre-jit-fixes that is missing 1
critical commit in pu
* no tests yet; would need to extend it on top of the debug from Beat
and test-tool changes from Ævar, neithe
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->pcre_tables);
> >>
> >> Is the cast really n
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.
> >> +if set to -1 will try first to use JIT and fallback to the
> >> +interpreter instead of returning an er
On Mon, Jul 29, 2019 at 5:38 AM Ævar Arnfjörð Bjarmason
wrote:
> On Mon, Jul 29 2019, Carlo Arenas wrote:
> > On Mon, Jul 29, 2019 at 1:55 AM Ævar Arnfjörð Bjarmason
> > wrote:
> >>
> >> On Mon, Jul 29 2019, Carlo Marcelo Arenas Belón wrote:
> >>
>
Junio
Thanks for fixing the conflicts in pu as well; apologize if I could
had made it easier by doings things differently
Carlo
On Wed, Jul 31, 2019 at 7:57 AM Ævar Arnfjörð Bjarmason
wrote:
> What hasn't been supported is all of that saying "yes, I support JIT"
> and the feature then fail whaling. I had not encountered that before.
>
> So far that seems like because Carlo just built a completely broken PCRE
> v2 package,
PROs:
* it works (only for PCRE2) and tested in OpenBSD, NetBSD, macOS, Linux (Debian)
* it applies everywhere (even pu) without conflicts
* it doesn't introduce any regressions in tests (tested in Debian with
SElinux in enforcing mode)
* it is simple
CONs:
* HardenedBSD still segfaults (bugfix pr
On Mon, Aug 5, 2019 at 4:51 AM Johannes Schindelin via GitGitGadget
wrote:
>
> Since 7d3bf769994 (grep: avoid leak of chartables in PCRE2, 2019-08-01),
> we try to release the UTF-8 tables obtained via `pcre2_maketables()`. To
> do that, we use the function `free()`. That is all fine and dandy as
And forgot to mention that technically these are not UTF-8 tables but
single byte tables like for example the ones used with en_US.ISO8859-1
Carlo
On Mon, Aug 5, 2019 at 2:53 PM Junio C Hamano wrote:
>
> Carlo Arenas writes:
>
> > LGTM except from the suggestion below that might make the code more
> > "standard"
> > and probably be a good base for a similar PCRE1 fix
> >>
> >>
On Sat, Oct 20, 2018 at 9:45 AM Torsten Bögershausen wrote:
>
> The motivation feels a little bit weak, at least to me.
I have to admit, I was sitting on this patch for a while for the same reason
but I should had made a more compelling commit message either way and
will definitely fix that with
I agree with you; dropped
On Tue, Oct 23, 2018 at 2:40 AM Junio C Hamano wrote:
>
> The tip of 'pu' has trouble with -Wunused on Apple around the
> delta-islands series.
FWIW the "problem" is actually with -Wunused-function and is AFAIK not
related to the semantic changes or Apple (AKA macOS)
Indeed, I saw this issue bef
On Tue, Oct 23, 2018 at 9:19 AM René Scharfe wrote:
> With Clang 6 and GCC 8 on Debian I don't get any warnings on master or
> 36da893114.
I see it with Clang 7 on Fedora (at least Rawhide but suspect also to
affect the next release, now in beta: 29)
> With Clang 6 on OpenBSD I get warnings abo
On Tue, Oct 23, 2018 at 3:00 PM Jeff King wrote:
> On Tue, Oct 23, 2018 at 02:50:19PM -0700, Carlo Marcelo Arenas Belón wrote:
> > #define implement_static_commit_slab(slabname, elemtype) \
> > - implement_commit_slab(slabname, elemtype, static MAYBE_UNUSED)
> > + implement_commit_slab(sl
On Wed, Oct 24, 2018 at 7:41 PM brian m. carlson
wrote:
> diff --git a/sha256/block/sha256.h b/sha256/block/sha256.h
> new file mode 100644
> index 00..38f02f7e6c
> --- /dev/null
> +++ b/sha256/block/sha256.h
> @@ -0,0 +1,26 @@
> +#ifndef SHA256_BLOCK_SHA256_H
> +#define SHA256_BLOCK_SHA25
On Wed, Oct 24, 2018 at 11:22 PM Junio C Hamano wrote:
> and they would read naturally. But may be it is a bit too cute an
> idea? I dunno.
my first idea was to replace it with a helper called touch_file, since
I was expecting it will be a popular operation as flag files are
common in shell scr
On Thu, Oct 25, 2018 at 1:08 AM Junio C Hamano wrote:
> For a single-use, not using the macro and just using "%s", "" should
> suffice.
OK, will send it as v2 then but would think it will be better if
applied as a "fixup" on top of the original branch:
34b47315d9 ("rebase -i: move rebase--helper
On Thu, Oct 25, 2018 at 2:09 PM Ramsay Jones
wrote:
> Yes, this will 'fix' the 'commit-reach.h' header (not surprising),
> but I prefer my patch. ;-)
I apologize, I joined the list recently and so might had missed a
reroll; the merged series in pu doesn't seem to include it and the
error was arou
On Fri, Nov 2, 2018 at 9:44 AM Johannes Sixt wrote:
>
> + timeout = elapsed >= orig_timeout ? 0 : (int)(orig_timeout - elapsed);
nitpick: cast to DWORD instead of int
Carlo
On Thu, Nov 1, 2018 at 10:24 PM Jeff King wrote:
>
> static void date_yesterday(struct tm *tm, struct tm *now, int *num)
> {
> + *num = 0;
the only caller (date_time) for this sends num = NULL, so this
triggers a segfault.
the only reference I could find to that apparently unused paramet
On Tue, Nov 13, 2018 at 12:49 AM Johannes Schindelin
wrote:
> On Mon, 12 Nov 2018, Carlo Marcelo Arenas Belón wrote:
>>
> > if time_t can't represent a valid time keep the indexes for failsafe
>
> Is this sentence incomplete? What are those "indexes"?
the indexes that are created when core.splitI
On Mon, Nov 19, 2018 at 4:28 AM Torsten Bögershausen wrote:
>
> Did you test it on Mac ?
macOS 10.14.1 but only using APFS, did you test my patch with HFS+?
> So what exactly are you trying to fix ?
I get
not ok 99 - colliding file detection
#
# grep X icasefs/warning &&
# grep x icasefs/warni
On Mon, Nov 19, 2018 at 10:40 AM Max Kirillov wrote:
>
> On Mon, Nov 19, 2018 at 02:15:35AM -0800, Carlo Marcelo Arenas Belón wrote:
> > 6c213e863a ("http-backend: respect CONTENT_LENGTH for receive-pack",
> > 2018-07-27)
> > introduced all tests but without a check for CURL support from git.
>
>
On Mon, Nov 19, 2018 at 9:23 AM Ramsay Jones
wrote:
> ok 99 # skip colliding file detection (missing !CYGWIN of
> !MINGW,!CYGWIN,CASE_INSENSITIVE_FS)
you need to enable this specific test first (removing !CYGWIN) so it
doesn't get skipped
Carlo
ok 99 - colliding file detection
as well in macOS with APFS
Carlo
Tested-by: Carlo Marcelo Arenas Belón
in macOS 10.14.1 with APFS
in Linux using VFAT (for the lulz)
IMHO it would be ideal if test would be enabled/validated for windows
(native, not only cygwin) as it might even work without the override
and if we are to see conflicts, that is probably where mo
Tested-by: Carlo Marcelo Arenas Belón
the C version prepends: "fatal: " unlike the shell version for both
error messages
Carlo
FWIW the issue goes away when more than 1 CPU is used in NetBSD 8,0
(32-bit) and for some tracing, it would seem that it gets 0 when
trying to read 4 bytes from what I think is a pipe that connects to a
child that has been gone already for a while.
Carlo
On Wed, Nov 21, 2018 at 2:49 PM Max Kirillov wrote:
>
> Should I install bash for it to work? I cannot say I understand what the
> message is about.
yes, you need to install bash and use SHELL_PATH=/usr/pkg/bin/bash;
PERL_PATH=/usr/pkg/bin/perl for the perl script
Carlo
On Wed, Nov 21, 2018 at 2:49 PM Max Kirillov wrote:
>
> On Wed, Nov 21, 2018 at 04:02:04AM -0800, Carlo Arenas wrote:
> > for some tracing, it would seem that it gets 0 when
> > trying to read 4 bytes from what I think is a pipe that connects to a
> > child that has been
On Wed, Nov 21, 2018 at 10:37 PM Max Kirillov wrote:
>
> On Wed, Nov 21, 2018 at 05:04:25PM -0800, Carlo Arenas wrote:
> > the last child of its children long gone with an error as shown by :
> >
> > 9255 1 git-http-backend CALL close(1)
> ...
> >
On Thu, Nov 22, 2018 at 3:43 PM Max Kirillov wrote:
> also edited the test to include only push_plain case,
> and repeat it several times, to avoid running irrelevant
> cases, the failure never happened again.
as I explained previously[1] and as odd as it might seem the
push_plain case ONLY
fails
Tested-by: Carlo Marcelo Arenas Belón
IMHO leaving the shebang might be better if only for consistency but
could go eitherway
Carlo
Signed-off-by: Carlo Marcelo Arenas Belón
clang with -Wpedantic also catch this (at least with Apple LLVM
version 10.0.0); recent versions of gcc also include that flag and at
least 8.2.0 shows a warning for it, so it might be worth adding it to
developer mode (maybe under the pedantic DEVOPTS),
On Tue, Nov 27, 2018 at 2:53 AM Eric Sunshine wrote:
> On Tue, Nov 27, 2018 at 5:06 AM Carlo Marcelo Arenas Belón
> > +ifneq ($(filter clang10,$(COMPILER_FEATURES)),)
> > +CFLAGS += -Wpedantic
> > +endif
>
> Should this condition be tightened to match only for OSX since there
> is no such clang ve
FWIW this patch doesn't have any other siblings and subject should had
been just [PATCH]; apologize for the confusion and the spam (including
that other duplicated email, and most likely this one)
Carlo
On Thu, Oct 18, 2018 at 12:36 PM Derrick Stolee wrote:
>
> Is there a tool that reports a wasted
> initialization that you used to find this?
I'd used clang's analyzer recently to track a similar issue before in a
different codebase, but not for this specific case.
Carlo
On Mon, Feb 11, 2019 at 4:35 PM Jeff King wrote:
>
> Ah, doubly puzzling. It works fine in my Debian dash (but fnmatch was
> enabled in 0.5.8-1 there, too).
FWIW, it is reported by both checkbashisms and shellcheck if "linting"
could be considered of help to track these kind of issues.
other "po
On Tue, Aug 6, 2019 at 10:38 PM René Scharfe wrote:
>
> Am 06.08.19 um 18:36 schrieb Carlo Marcelo Arenas Belón:
> > Move some of the logic that was before done per thread (in the workers)
> > into an earlier phase to avoid degrading performance
>
> Which logic is moved? In the patch I basically
Subject was meant to be "gettext: fix is_utf8_locale() when not using
NO_GETTEXT" and affects mainly PCRE by using UTF-8 flag even when the
locale was ISO.
somehow it doesn't break any tests though, but PCRE strongly advices
against doing both UTF and chartables and we might end up doing that
more
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
>
> nedmalloc works on other platforms as well.
I meant[1] it works reliably
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 Arenas:
> >>> was hoping will perform better but it se
On Thu, Aug 8, 2019 at 6:57 AM Johannes Schindelin
wrote:
> On Tue, 6 Aug 2019, Carlo Marcelo Arenas Belón wrote:
> > Suggested-by: Johannes Schindelin
>
> Actually not so much suggested by me, as your patch still causes
> crashes (mine didn't):
the "equivalent" version in v4[1], that is still n
On Thu, Aug 8, 2019 at 6:55 AM Johannes Schindelin
wrote:
> On Tue, 6 Aug 2019, Carlo Marcelo Arenas Belón wrote:
>
> > 63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09) didn't include a way
> > to override the system allocator, and so it is incompatible with
> > USE_NED_ALLOCATOR as reported by Ds
On Thu, Aug 8, 2019 at 1:21 PM Johannes Schindelin
wrote:
> On Tue, 6 Aug 2019, Carlo Marcelo Arenas Belón wrote:
> > Eitherway, since I am unable to replicate the original bug or take
> > performance numbers in a representative environment without Windows
> > this is only published as an RFC, eve
disregard this version, it still broken (and wouldn't even build on
some cases), the reasons why are still unclear though but at least it
might
seem from the last known run in windows that segfaults were prevented
at last and something was still off enough to trigger a BUG (shouldn't
be a concern w
On Fri, Aug 9, 2019 at 2:26 PM Johannes Schindelin
wrote:
>
> FWIW I am very much in favor of this approach.
FWIW this is (almost) exactly what I had in mind with my first reply,
except I wanted to make setting of the global context be conditioned
to having NED enabled to avoid possible performan
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 selected at compile time.
>
> A custom general context is needed to convince PCRE2 to use xma
On Sat, Aug 10, 2019 at 12:57 AM René Scharfe wrote:
>
> 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é&#
On Sat, Aug 10, 2019 at 3:17 PM Daniel Stenberg wrote:
>
> On Sat, 10 Aug 2019, Carlo Marcelo Arenas Belón wrote:
>
> > tested in macOS 10.14.6 with the system provided cURL (7.54.0)
> > and latest (7.65.3) and while the API used should be added starting around
> > 7.12.0 (mid 2014).
>
> Let me ju
On Sun, Aug 11, 2019 at 4:20 AM Johannes Schindelin
wrote:
> On Sat, 10 Aug 2019, Carlo Marcelo Arenas Belón wrote:
> > cURL is very strict about its allocator being thread safe and so that might
> > be an issue to look for.
>
> Looks good to me.
it is not ready yet for using though, at minimum I
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 don't mind, sounds good.
I had to squash another fix that was reported[1] before but wasn't picked up
On Mon, Aug 12, 2019 at 5:14 AM René Scharfe wrote:
>
> That looks like an issue worth its own commit.
OK, but then will make my topic interesting; indeed it almost feels
like it should be 3 different topics all depending of each other in a
chain:
* really use the match context
* move to xmalloc
On Wed, Aug 14, 2019 at 4:58 PM Matheus Tavares Bernardino
wrote:
>
> On Wed, Aug 14, 2019 at 6:27 PM Junio C Hamano wrote:
> >
> [...]
> > * mt/grep-submodules-working-tree (2019-07-30) 1 commit
> > (merged to 'next' on 2019-08-02 at e1a46a195f)
> > + grep: fix worktree case in submodules
>
>
On Mon, Aug 19, 2019 at 3:23 PM Junio C Hamano wrote:
>
> There may be others I am missing.
should we still support PCRE1? I think in this case the problem is
compounded by the fact that unless we do something like [1], the real
fix for those UTF-8 validation issues will require a yet unreleased
On Mon, Aug 26, 2019 at 7:29 AM Johannes Schindelin
wrote:
>
> On Sat, 24 Aug 2019, Carlo Arenas wrote:
>
> > On Mon, Aug 19, 2019 at 3:23 PM Junio C Hamano wrote:
> > >
> > > There may be others I am missing.
> >
> > should we still support PCRE1
On Mon, Aug 26, 2019 at 9:02 AM Junio C Hamano wrote:
>
> Carlo Arenas writes:
>
> > ... but
> > ab/pcre-jit-fixes and UTF-8 validation are likely to make that more
> > difficult (even if it is a mostly self inflicted wound AFAIK)
>
> Hmm, in what way? Do yo
1 - 100 of 108 matches
Mail list logo
