From: Jeff King <firstname.lastname@example.org>
To: Junio C Hamano <email@example.com>
Cc: "René Scharfe" <firstname.lastname@example.org>,
"Ævar Arnfjörð Bjarmason" <email@example.com>,
"Git List" <firstname.lastname@example.org>
Subject: Re: [PATCH] tree-walk: disallow overflowing modes
Date: Thu, 26 Jan 2023 06:36:02 -0500 [thread overview]
Message-ID: <Y9JlouutFD21lvna@coredump.intra.peff.net> (raw)
On Tue, Jan 24, 2023 at 12:44:16PM -0800, Junio C Hamano wrote:
> René Scharfe <email@example.com> writes:
> > ... It's basically harmless. Perhaps
> > we just need a comment stating that, to contain the urge to "fix" this.
> Yeah, especially since fsck finds and warns about bad mode with
> FSCK_MSG_BAD_FILEMODE and also FSCK_MSG_ZERO_PADDED_FILEMODE in a
> separate codepath, adding another piece of code that checks a
> slightly different condition does not sound like a good idea.
Yeah, I'm happy to drop this whole thing. I do think it would be
reasonable for fsck to check for overflow alongside BAD_FILEMODE, etc,
but it's annoying to do since we are relying on the existing parser.
I actually have a suspicion that it might be reasonable for fsck to just
parse the trees itself, rather than relying on decode_tree_entry(), etc.
But that's a much bigger topic (and a possible maintenance burden) for
questionable gain, so unless we find some compelling reason (some case
that we really want to detect but which we want the regular decoder to
ignore), it's probably not worth exploring.
prev parent reply other threads:[~2023-01-26 11:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-21 9:36 [PATCH] tree-walk: disallow overflowing modes René Scharfe
2023-01-22 7:50 ` Jeff King
2023-01-22 10:03 ` René Scharfe
2023-01-22 16:36 ` Junio C Hamano
2023-01-22 22:02 ` Jeff King
2023-01-23 8:33 ` Ævar Arnfjörð Bjarmason
2023-01-24 18:53 ` René Scharfe
2023-01-24 20:44 ` Junio C Hamano
2023-01-26 11:36 ` Jeff King [this message]
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:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.
Code repositories for project(s) associated with this public inbox
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 read-only IMAP folder(s) and NNTP newsgroup(s).