On Sat, Dec 15, 2018 at 2:08 PM Bruno Haible <[email protected]> wrote: > Hi Jim, > > > I guess the fix should be to detect the glibc bug in m4/regex.m4 ? > > > > Exactly. That's what I'm doing now. > > I'm expecting to insert something like this, probably reusing the > > result value of "64": > > > > /* Matching with the compiled form of this regexp would > > provoke > > an assertion failure prior to glibc-2.28: > > regexec.c:1375: pop_fail_stack: Assertion `num >= 0' > > failed > > With glibc-2.28, compilation fails and reports the > > invalid > > back reference. */ > > re_set_syntax (RE_SYNTAX_POSIX_EGREP); > > memset (®ex, 0, sizeof regex); > > s = re_compile_pattern ("0|()0|\\1|0", 10, ®ex); > > if (!s || strcmp (s, "Invalid back reference")) > > result |= 64; > > > > Looks good to me (modulo the line breaks that are probably caused > by your MUA). > > Yes, we have to reuse some of the bits, because a program's return > code (> 0, < 126) has only room for 7 bits. > > This test should also be added to tests/test-regex.c, so that we > verify that the choices made by regex.m4 have really achieved their > objective.
Thanks. I've just pushed this: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=55a4abd92a0a8fa0a9d9aff3892505f7b0c6d73c Tested both this ./gnulib-tool --create-testdir --test --dir /t/x --with-tests regex and via bulding/testing grep on a Debian system. Before, both would fail. After, they both pass.
