Re: [PATCH v4 next 00/23] Enhance printf()

["Thomas Weißschuh" <linux@weissschuh.net>]

On 2026-03-07 22:03:48+0000, David Laight wrote:
> On Sat, 7 Mar 2026 19:02:30 +0100
> Thomas Weißschuh <linux@weissschuh.net> wrote:
> 
> > Hi David,
> > 
> > On 2026-03-02 10:17:52+0000, david.laight.linux@gmail.com wrote:
> > > From: David Laight <david.laight.linux@gmail.com>  
> > 
> > (...)
> > 
> > I am happy with the patches of this series.
> > 
> > > David Laight (23):
> > >   tools/nolibc: Add _NOLIBC_OPTIMIZER_HIDE_VAR() to compiler.h  
> > 
> > >   tools/nolibc/printf: Move snprintf length check to callback
> > >   selftests/nolibc: Return correct value when printf test fails
> > >   selftests/nolibc: check vsnprintf() output buffer before the length
> > >   selftests/nolibc: Use length of 'expected' string to check snprintf() output
> > >   selftests/nolibc: Check that snprintf() doesn't write beyond the buffer end
> > >   selftests/nolibc: Let EXPECT_VFPRINTF() tests be skipped  
> > 
> > >   selftests/nolibc: Rename w to written in expect_vfprintf()  
> > 
> > Unfortunately b4 chokes on these patches because this patch is missing
> > the 'v4' tag in the subject prefix.
> 
> I noticed that after sending them.
> I add it by hand (there might be an easier way) but it is easy to
> miss it when doing a final check/update of the patches.
> I then sent them without a final-final check.

git send-email/format-patch have --reroll-count for that.
b4 does manages the reroll count automatically.

> > Given that the one below needs some
> > changes anyways, I was lazy and applied the series only up until here.
> > (Patch 1 is also not applied, as there was no user yet for
> > _NOLIBC_OPTIMIZER_HIDE_VAR() ).
> > 
> > Could you rebase the series on nolibc-next, add the error handling
> > to strerror_r(), fix the wording nitpicks from Willy and resend the
> > patches? I can also try to fix this up locally, but that would be more
> > work on my side than it would be for you I reckon.
> > Let me know if this is an issue and I'll try to make it work.
> 
> That shouldn't be too hard.
> Was a right PITA moving them from linus's tree because --3way doesn't
> work when the patches come from different git trees.
> I'll just create a new branch, use 'git am' to apply each patch
> then edit and amend.
> Then recover all the info after the --- line.
> I'm getting used to that sequence :-)

This looks like a usecase for 'git rebase (--onto)'.

In any case: Thanks!


Thomas