bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: Jim Meyering <jim@meyering.net>
Cc: bug-gnulib@gnu.org, GNU grep developers <grep-devel@gnu.org>
Subject: Re: new snapshot available: grep-3.1.46-504af
Date: Sat, 15 Dec 2018 23:08:08 +0100	[thread overview]
Message-ID: <9201108.UyP5hulylU@omega> (raw)
In-Reply-To: <CA+8g5KGumQSMO82BKDsYUAuTzzkAAAZ+H1qqzy1-HiU0AOxbaA@mail.gmail.com>

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.

Bruno



       reply	other threads:[~2018-12-15 22:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <lubpf3h8feabk5.fsf@meyering.net>
     [not found] ` <57223855.0cMppWhKHm@omega>
     [not found]   ` <CA+8g5KGumQSMO82BKDsYUAuTzzkAAAZ+H1qqzy1-HiU0AOxbaA@mail.gmail.com>
2018-12-15 22:08     ` Bruno Haible [this message]
2018-12-15 23:32       ` new snapshot available: grep-3.1.46-504af Jim Meyering
2018-12-16 22:52 ` grep-3.1.46-504af on Minix Bruno Haible
     [not found] ` <20181216204837.GM28727@calimero.vinschen.de>
     [not found]   ` <20181216205140.GN28727@calimero.vinschen.de>
2018-12-19  7:51     ` [Grep-devel] handling of non-BMP characters Bruno Haible
2018-12-19 14:41       ` Corinna Vinschen
2018-12-19 14:44         ` Corinna Vinschen
2018-12-19 17:21       ` Jim Meyering
2018-12-19 22:54       ` Paul Eggert
2018-12-20  6:49         ` arnold
2018-12-20 11:30           ` Bruno Haible

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9201108.UyP5hulylU@omega \
    --to=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    --cc=grep-devel@gnu.org \
    --cc=jim@meyering.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).