[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[roessler@guug.de: Bug#63658: bug#124: Regular Expressions]

reassign 63658 libc6

Regex support is buggy.
You can find the whole story and test cases in the other bug messages.

--- Begin Message ---
On 2000-05-14 16:53:05 +0200, Andreas Metzler wrote:

> color body yellow blue "^ {0,3}([|>:}#] ?){3}.*"

OK...  I saved your message to the file /tmp/test, and
used the following minimal grep-like program to test


#include <stdio.h>
#include <regex.h>

int main (int argc, char *argv[])
  FILE *fp;
  regex_t preg;
  int ec;
  char buff[2048];
  if (argc == 2)
    fp = stdin;
  else if (argc == 3 && (fp = fopen (argv[2], "r")) == NULL)
    perror (argv[2]);
    exit (1);
  else if (argc > 3 || argc < 2)
    exit (1);
  if ((ec = regcomp (&preg, argv[1], REG_ICASE|REG_EXTENDED)) != 0)
    char e[1024];
    regerror (ec, &preg, e, sizeof (e));
    fputs (e, stderr);
    exit (1);
  while (fgets (buff, sizeof (buff), fp))
    if (regexec (&preg, buff, 0, NULL, 0) == 0)
      fputs (buff, stdout);
  fclose (fp);
  return 0;

I called the program like this:

./a.out '^ {0,3}([|>:}#] ?){3}.*' /tmp/test

The result:

>> blah fasel

- which should normally not be matched.  This effect went
away when I removed the " ?" inside the bracket.

This was reproducible with (1) the regcomp/regexec
implementation from glibc 2 (this is on a Debian Slink
system), and (2) the regex.c code we include with the mutt
source.  I did not check whether these implementations are
the same.

Now, either I'm missing a regular expression precedence
error, or there is a bug which is common to both regexp
implementations.  Or there is a problem with the way my
minimal grep and mutt use regcomp/regexec.

Funny enough, the problem does not occur with the GNU grep
2.2 on my system, which may mean that GNU grep is using a
different POSIX regexp implementation.

Note, BTW, that using GNU rx is not an option.  We have
had too many segmentation faults with that library in the
past, which look worse to me than this problem.

You may wish to reassign the Debian instance of this bug
report to glibc.  However, I'd be interested in any fixes
affecting the regex.c code.


--- End Message ---

Reply to: