From: Patrick Steinhardt <ps@pks.im>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org,
"Carlos Andrés Ramírez Cataño" <antaigroupltda@gmail.com>
Subject: Re: [PATCH 7/7] fsck: handle NULL value when parsing message config
Date: Thu, 7 Dec 2023 09:15:00 +0100 [thread overview]
Message-ID: <ZXF_BHFubnPJWNhQ@tanuki> (raw)
In-Reply-To: <20231207071135.GG1276005@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 2380 bytes --]
On Thu, Dec 07, 2023 at 02:11:35AM -0500, Jeff King wrote:
> When parsing fsck.*, receive.fsck.*, or fetch.fsck.*, we don't check for
> an implicit bool. So any of:
>
> [fsck]
> badTree
> [receive "fsck"]
> badTree
> [fetch "fsck"]
> badTree
>
> will cause us to segfault. We can fix it with config_error_nonbool() in
> the usual way, but we have to make a few more changes to get good error
> messages. The problem is that all three spots do:
>
> if (skip_prefix(var, "fsck.", &var))
>
> to match and parse the actual message id. But that means that "var" now
> just says "badTree" instead of "receive.fsck.badTree", making the
> resulting message confusing. We can fix that by storing the parsed
> message id in its own separate variable.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> builtin/receive-pack.c | 11 +++++++----
> fetch-pack.c | 12 ++++++++----
> fsck.c | 8 ++++++--
> 3 files changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> index 8c4f0cb90a..ccf9738bce 100644
> --- a/builtin/receive-pack.c
> +++ b/builtin/receive-pack.c
> @@ -142,6 +142,7 @@ static enum deny_action parse_deny_action(const char *var, const char *value)
> static int receive_pack_config(const char *var, const char *value,
> const struct config_context *ctx, void *cb)
> {
> + const char *msg_id;
> int status = parse_hide_refs_config(var, value, "receive", &hidden_refs);
>
> if (status)
> @@ -178,12 +179,14 @@ static int receive_pack_config(const char *var, const char *value,
> return 0;
> }
>
> - if (skip_prefix(var, "receive.fsck.", &var)) {
> - if (is_valid_msg_type(var, value))
> + if (skip_prefix(var, "receive.fsck.", &msg_id)) {
> + if (!value)
> + return config_error_nonbool(var);
> + if (is_valid_msg_type(msg_id, value))
> strbuf_addf(&fsck_msg_types, "%c%s=%s",
> - fsck_msg_types.len ? ',' : '=', var, value);
> + fsck_msg_types.len ? ',' : '=', msg_id, value);
> else
> - warning("skipping unknown msg id '%s'", var);
> + warning("skipping unknown msg id '%s'", msg_id);
> return 0;
> }
Same remark here. We would only generate warnings for an actual boolean,
so I'd think we might consider doing the same for implicit booleans.
Partick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-12-07 8:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-07 7:10 [PATCH 0/7] fix segfaults with implicit-bool config Jeff King
2023-12-07 7:11 ` [PATCH 1/7] config: handle NULL value when parsing non-bools Jeff King
2023-12-07 8:14 ` Patrick Steinhardt
2023-12-12 0:58 ` Jeff King
2023-12-07 7:11 ` [PATCH 2/7] setup: handle NULL value when parsing extensions Jeff King
2023-12-07 7:11 ` [PATCH 3/7] trace2: handle NULL values in tr2_sysenv config callback Jeff King
2023-12-07 7:11 ` [PATCH 4/7] help: handle NULL value for alias.* config Jeff King
2023-12-07 7:11 ` [PATCH 5/7] submodule: handle NULL value when parsing submodule.*.branch Jeff King
2023-12-07 8:14 ` Patrick Steinhardt
2023-12-12 0:46 ` Jeff King
2023-12-07 7:11 ` [PATCH 6/7] trailer: handle NULL value when parsing trailer-specific config Jeff King
2023-12-07 8:14 ` Patrick Steinhardt
2023-12-07 7:11 ` [PATCH 7/7] fsck: handle NULL value when parsing message config Jeff King
2023-12-07 8:15 ` Patrick Steinhardt [this message]
2023-12-07 8:14 ` [PATCH 0/7] fix segfaults with implicit-bool config Patrick Steinhardt
2023-12-12 0:52 ` Jeff King
2023-12-12 4:10 ` Patrick Steinhardt
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=ZXF_BHFubnPJWNhQ@tanuki \
--to=ps@pks.im \
--cc=antaigroupltda@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.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