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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.