Re: [PATCH 5/8] pretty: after padding, reset padding info

From: Martin Ågren <martin.agren@gmail.com>
Date: Mar 20, 2025, 16:11 UTC
Message-ID: <CAN0heSovtPNpyHEUC8m48zyJkRxGQNwp5u6x=WDMdd+aNJnwjw@mail.gmail.com>
In-Reply-To: <Z9vdTmVbIJLa9PGO@pks.im>

On Thu, 20 Mar 2025 at 10:18, Patrick Steinhardt <ps@pks.im> wrote:

>
> On Wed, Mar 19, 2025 at 08:23:38AM +0100, Martin Ågren wrote:

Show 12 quoted lines

> Yeah, I agree. It's very surprising that we retain only a subset of
> state, and that does feel like a bug to me.
>
> >       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.

Good point. I'll make the preceding commit use a new `padding_args_clear()`, then reuse it here.

BTW, we rely on initializing the struct with all-zeroes to put it in this cleared state. Which is true, since the "none"/"no" enum members are indeed zero. That's not explicit though. I'm thinking of adding a preparatory patch to make `no_flush` and `trunc_none` be explicitly zero, and see if there are other such enum values in this file.

Martin