On Thu, Oct 27, 2022 at 07:13:08PM +0200, Willy Tarreau wrote: > On Thu, Oct 27, 2022 at 10:04:53AM -0700, Paul E. McKenney wrote: > > > > My intent is to push these nolicb patches into the upcoming v6.2 > > > > merge window: > > > > > > > > 2318a710bffbd tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12 > > > > 6937b8de8f1c3 tools/nolibc/string: Fix memcmp() implementation > > > > e1bbfe393c900 selftests/nolibc: Add 7 tests for memcmp() > > > > 3f2c1c45a3a9a selftests/nolibc: Always rebuild the sysroot when running a test > > > > > > > > I didn't see the problem until I queued the third patch (e1bbfe393c900), > > > > and it is still in -rcu, not in v6.1. > > > > > > > > What am I missing here? > > > > > > I thought that since some of them are fixes, they would be pushed during > > > 6.1-rc so that we don't release 6.1 with known defects. For example Rasmus' > > > fix for memcmp() or the strlen() fix would IMHO make sense for this > > > release since we're aware of the bugs and we have the fixes. The 3rd one > > > is indeed an addition and in no way a fix and it can easily wait for 6.2. > > > The 4th one is more of a usability fix but I agree that for this last one > > > it's debatable, I was mostly seeing this as a possiility to avoid causing > > > needless confusion. > > > > > > Hoping this clarifies my initial question. > > > > Very much so, thank you! > > > > I was not considering the bug fixed by the first two patches to be > > serious, my mistake, apologies for my misclassification. > > No worries, I wasn't probably clear upfront about the purpose. > > > Given that background, I would rebase these two, test them, and send > > off a pull request, probably early next week. > > > > 2318a710bffbd tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12 > > 6937b8de8f1c3 tools/nolibc/string: Fix memcmp() implementation > > Perfect, thank you! > > > I would push the other two commits into the upcoming merge window. > > OK! > > > Or might the discussion between you and Rasmus result in changes to > > either of those first two commits? If so, I should of course wait for > > that discussion to resolve. > > We'll see, but in any case it would just be a minor detail, but I'll > give you a quick response so that you don't have to deal with multiple > versions of the patch, we all know that it's painful. If I don't hear otherwise from you by the end of tomorrow (Friday), Pacific Time, I will rebase those two patches in preparation for sending a pull request for the regression. I will of course run the pull-message text past you before sending the pull request. Thanx, Paul
