From: Junio C Hamano <gitster@pobox.com>
To: Mathias Krause <minipli@grsecurity.net>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
git@vger.kernel.org,
"Carlo Marcelo Arenas Belón" <carenas@gmail.com>
Subject: Re: [PATCH] grep: fall back to interpreter mode if JIT fails
Date: Sat, 17 Dec 2022 08:09:40 +0900 [thread overview]
Message-ID: <xmqqlen7kksr.fsf@gitster.g> (raw)
In-Reply-To: <62a06c5b-9646-17f8-b4d5-39823d3cc25a@grsecurity.net> (Mathias Krause's message of "Fri, 16 Dec 2022 20:26:26 +0100")
Mathias Krause <minipli@grsecurity.net> writes:
> ... However, from a user's point of view a fall back to
> interpreter mode might still be desired in this case, as a failing
> 'git grep' is simply not acceptable, IMHO.
"git grep" that silently produces a wrong result (by falling back
after a problem is detected) would not be acceptable, either.
Receiving BADOPTION could be a sign that there is something wrong in
the input, not from the end-user but from the code, in which case
stopping with BUG() may be a more appropriate?
>> I put a BUG() there, we could keep the die(), but
>> PCRE2_ERROR_JIT_BADOPTION is really more appropriate as a BUG(), and if
>> it starts returning any other codes our use of the API is also in some
>> unknown state, so we should also BUG() out.
>
> Valid points. I'll give others some more time to churn in and if there
> are no strong objections, I'll change it like you suggest.
Yup, sounds quite sensible.
next prev parent reply other threads:[~2022-12-16 23:10 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 12:15 [PATCH] grep: fall back to interpreter mode if JIT fails Mathias Krause
2022-12-16 16:12 ` Ævar Arnfjörð Bjarmason
2022-12-16 19:26 ` Mathias Krause
2022-12-16 23:09 ` Junio C Hamano [this message]
2022-12-17 2:50 ` Carlo Arenas
2022-12-19 9:00 ` Ævar Arnfjörð Bjarmason
2022-12-20 19:29 ` Mathias Krause
2022-12-20 21:11 ` Ævar Arnfjörð Bjarmason
2023-01-18 14:22 ` Mathias Krause
2023-01-18 15:44 ` Ævar Arnfjörð Bjarmason
2023-01-19 9:19 ` Mathias Krause
2022-12-16 22:52 ` Junio C Hamano
2022-12-20 20:40 ` Mathias Krause
2023-01-27 15:49 ` [PATCH v2] grep: fall back to interpreter if JIT memory allocation fails Mathias Krause
2023-01-27 16:34 ` Junio C Hamano
2023-01-27 17:39 ` Junio C Hamano
2023-01-27 18:46 ` Junio C Hamano
2023-01-29 13:37 ` Mathias Krause
2023-01-29 13:36 ` Mathias Krause
2023-01-29 17:15 ` Junio C Hamano
2023-01-30 10:56 ` Ævar Arnfjörð Bjarmason
2023-01-30 18:49 ` Junio C Hamano
2023-01-31 8:34 ` Ævar Arnfjörð Bjarmason
2023-01-30 11:08 ` Mathias Krause
2023-01-30 18:54 ` Junio C Hamano
2023-01-30 20:08 ` Junio C Hamano
2023-01-30 21:21 ` Junio C Hamano
2023-01-30 22:30 ` Ramsay Jones
2023-01-30 23:27 ` Junio C Hamano
2023-01-31 7:48 ` Mathias Krause
2023-01-31 16:41 ` Junio C Hamano
2023-01-31 18:34 ` Mathias Krause
2023-01-31 7:30 ` Mathias Krause
2023-01-29 12:28 ` Mathias Krause
2023-01-31 18:56 ` [PATCH v3] " Mathias Krause
2023-01-31 21:05 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqlen7kksr.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=carenas@gmail.com \
--cc=git@vger.kernel.org \
--cc=minipli@grsecurity.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).