From: Patrick Steinhardt <ps@pks.im>
To: "Martin Ågren" <martin.agren@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 5/8] pretty: after padding, reset padding info
Date: Thu, 20 Mar 2025 10:18:06 +0100 [thread overview]
Message-ID: <Z9vdTmVbIJLa9PGO@pks.im> (raw)
In-Reply-To: <e34ae37982e76179aee780c70b48aaaf959a307b.1742367347.git.martin.agren@gmail.com>
On Wed, Mar 19, 2025 at 08:23:38AM +0100, Martin Ågren wrote:
> After handling a padding directive ("%<" or "%>"), we leave the `struct
> padding_args` in a halfway state. We modify it a bit as we apply the
> padding/truncation so that by the time we're done, it can't be in quite
> as many states as when we started. Still, we don't fully restore it to
> its default, no-action state.
>
> "%<" and "%>" should only affect the next placeholder, but leaving a bit
> of state around doesn't make it obvious that we don't spill any of it
> into our handling of later placeholders. The previous commit closed off
> a way of populating only half the `struct padding_args`, thereby fixing
> a bug that *also* relied on then having the other half contain this kind
> of lingering data.
>
> After that fix, I haven't figured out a way to provoke a bug using just
> this here half of the issue. Still, after handling padding, let's drop
> all remnants of the previous "%<" or "%>".
>
> Unlike the bug fixed in the previous commit, this could have some
> realistic chance of regressing something for someone if they've actually
> been using such state leftovers (knowingly or not). Still, it seems
> worthwhile to try to tighten this.
Yeah, I agree. It's very surprising that we retain only a subset of
state, and that does feel like a bug to me.
> This change to pretty.c would have been sufficient to make the test
> added in the previous commit pass. Belt and suspenders.
>
> Signed-off-by: Martin Ågren <martin.agren@gmail.com>
> ---
> pretty.c | 2 ++
> t/t4205-log-pretty-formats.sh | 9 +++++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/pretty.c b/pretty.c
> index a4fa052f8b..f53e77ed86 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -1893,6 +1893,8 @@ static size_t format_and_pad_commit(struct strbuf *sb, /* in UTF-8 */
> }
> strbuf_release(&local_sb);
> c->pad.flush_type = no_flush;
> + c->pad.truncate = trunc_none;
> + c->pad.padding = 0;
> return total_consumed;
> }
This is using the same default values now as you started to use in the
preceding commit. It might make sense to introduce a macro or function
to initialize the structure so that we don't duplicate initialization.
Patrick
next prev parent reply other threads:[~2025-03-20 9:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-19 7:23 [PATCH 0/8] pretty: minor bugfixing, some refactorings Martin Ågren
2025-03-19 7:23 ` [PATCH 1/8] pretty: tighten function signature to not take `void *` Martin Ågren
2025-03-20 9:18 ` Patrick Steinhardt
2025-03-19 7:23 ` [PATCH 2/8] pretty: simplify if-else to reduce code duplication Martin Ågren
2025-03-20 9:17 ` Patrick Steinhardt
2025-03-20 16:10 ` Martin Ågren
2025-03-24 3:50 ` Jeff King
2025-03-19 7:23 ` [PATCH 3/8] pretty: collect padding-related fields in separate struct Martin Ågren
2025-03-19 7:23 ` [PATCH 4/8] pretty: fix parsing of half-valid "%<" and "%>" placeholders Martin Ågren
2025-03-20 9:18 ` Patrick Steinhardt
2025-03-20 16:11 ` Martin Ågren
2025-03-24 10:10 ` Patrick Steinhardt
2025-03-19 7:23 ` [PATCH 5/8] pretty: after padding, reset padding info Martin Ågren
2025-03-20 9:18 ` Patrick Steinhardt [this message]
2025-03-20 16:11 ` Martin Ågren
2025-03-19 7:23 ` [PATCH 6/8] pretty: refactor parsing of line-wrapping "%w" placeholder Martin Ågren
2025-03-20 9:18 ` Patrick Steinhardt
2025-03-20 16:11 ` Martin Ågren
2025-03-19 7:23 ` [PATCH 7/8] pretty: refactor parsing of magic Martin Ågren
2025-03-20 9:18 ` Patrick Steinhardt
2025-03-20 16:12 ` Martin Ågren
2025-03-19 7:23 ` [PATCH 8/8] pretty: refactor parsing of decoration options Martin Ågren
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=Z9vdTmVbIJLa9PGO@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=martin.agren@gmail.com \
/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).