Re: [PATCH] grep: under --debug, show whether PCRE JIT is enabled

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 19, 2019, 22:23 UTC
Message-ID: <xmqqk1b8x0ac.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190818201727.31505-1-dev+git@drbeat.li>

Beat Bolli <dev+git@drbeat.li> writes:

Show 7 quoted lines

> This information is useful and not visible anywhere else, so show it.
>
> Signed-off-by: Beat Bolli <dev+git@drbeat.li>
> Suggested-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> ---
> This applies on top of 'ab/pcre-jit-fixes', currently in pu.

Thanks.

We saw a few people exchanging patches on the list and discussing topics aroud PCRE and especially JIT, but the discussion petered out during the prerelease freeze. I'd like to see the topics solidify early in this cycle.

IIRC, some key points/issues addressed by various patches we saw during the last cycle were:

 - A binary may be prepared to be JIT capable, but on a particular
   system (e.g. SELinux) JIT may not work.  Should we write off such
   a configuration as "broken"?  Should we just fall back on non-JIT?
   Should we fall back with loud warning?

 - JIT and non-JIT codepath may validate UTF-8 differently without
   care, but we should make sure JIT codepath behave identically to
   non JIT (only faster).

 - We should not be validating strict UTF-8 when we do not even know
   if the payload is UTF-8.  What mechanism, if any, do we have to
   let us say "this must be UTF-8 or otherwise it is an error" with
   confidence?  Should we error out in the middle of "git log"
   session upon seeing a binary haystack while looking for UTF-8
   needle (I think not)?

There may be others I am missing.

Is ab/pcre-jit-fixes a good base to collectively work on to finish the topics floated around PCRE during the last cycle?

I'll queue this debugging aid on top in the meantime.  Thanks.