glibc test time regression after gawk update

[arnold@skeeve.com]

Florian,

Any updates on this issue?

Thanks,

Arnold

arnold@skeeve.com wrote:

> Florian,
>
> You may also wish to check your data.  If there are invalid multibyte
> sequences that you expect to match, they likely won't. See the thread
> starting at:
>
> 	https://lists.gnu.org/archive/html/bug-gawk/2026-02/msg00031.html
>
> and Mike Haertel's note at
>
> 	https://lists.gnu.org/archive/html/bug-gawk/2026-02/msg00034.html
>
> Thanks,
>
> Arnold
>
> arnold@skeeve.com wrote:
>
> > Hi.
> >
> > The GNU matchers are available by setting GAWK_GNU_MATCHERS to any
> > value in the environment. But they will be removed from gawk in
> > release 6.0, which I hope will be in about a year's time, so this
> > issue should be solved now.
> >
> > What locale do you run the tests in? If a UTF-8 locale, it should
> > still work.
> >
> > Using the C locale may be the smartest thing to do long term.
> >
> > If you can isolate the failing behavior into a small test case with
> > as few lines of input data as possible, I can try to take a look.
> >
> > Another option is to use git bisect on gawk to isolate the commit
> > where things changed.
> >
> > Thanks,
> >
> > Arnold
> >
> > Florian Weimer <fweimer@redhat.com> wrote:
> >
> > > It looks like we have a very substantial test time regression in glibc
> > > after a gawk update.  Based on quick poking with GDB, it may be related
> > > to the MinRX change in gawk 5.4.0.
> > >
> > > This is the script:
> > >
> > >   <https://sourceware.org/cgit/glibc/tree/stdio-common/tst-printf-format.awk>
> > >
> > > Is this expected?  The input files can be quite large, with very long
> > > lines, too.
> > >
> > > I suppose we can switch back to the old matcher (will that remain
> > > available?), or maybe run it under the C locale.
> > >
> > > Thanks,
> > > Florian
> > >