On Sat, Dec 15, 2018 at 2:08 PM Bruno Haible <br...@clisp.org> 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 (&regex, 0, sizeof regex);
> >             s = re_compile_pattern ("0|()0|\\1|0", 10, &regex);
> >             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.

Reply via email to