glibc test time regression after gawk update

[arnold@skeeve.com]

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
> >