Etags (Emacs 22.2) -- miscompiles multiline user regexes

[Derek Peschel]

When using etags's --regex option and the m modifier after the expression,
I've been seeing one of two things:

  - etags complains about an unterminated [ or [^, or unmatched \(,
    even though the expression is well-formed

  - etags doesn't complain but the expression matches more lines than
    it should (e.g. an expression ending with the literal text ___P
    also matches lines containing ___ and any other letter)

These happen whether or not the expression has a name subexpression.
Finally I realized one bug might cause both behaviors: not scanning the
entire tag subexpression, but instead omitting the last character from
the scan.  Adding a space after the tag subexpression on the command line
fixes the error or produces the proper number of matches.

Editing regex.c to set debug to a positive value, and recompiling with
DEBUG defined, shows that the compiled text is indeed too short.  Probably
this line in add_regex (in etags.c) is the cause:

  err = re_compile_pattern (pat, strlen (regexp_pattern), patbuf);

Notice how pat is passed as the string but the length of regexp_pattern
(not pat) is passed.  And because of the concat a few lines above,
the two strings differ in length by one character when the m modifier
is used.

Incidentally, regex.c mentions iregex.c and main.c but those files don't
seem to be distributed with etags.  They might have made this problem
easier to find.

Let me know if you have questions or want test cases.

-- Derek