Ramsay Jones <ram...@ramsay1.demon.co.uk> writes:

> I had the same problem (or at least it *looks* like the same problem) on Linux
> last year (May 2011), which turned out to be a bug in the regex routines in an
> old version of glibc. 
> I don't know OS X at all, so this may not be relevent; does OS X use glibc?
> (I didn't think so, but ...)
> I sent some patches to the list which may be helpful. I can't get to gmane to
> look up a reference, but you need to search for:
>     [RFC/PATCH] userdiff.c: Avoid old glibc regex bug causing t4034-*.sh test 
> failures
> sent on 3rd May 2011.

Thanks; that's $gmane/172676 for people who prefer easier to read
threading interface.

> Also, in the same thread, a reply to Jonathan Nieder on 7th May contains a
> test which checks whether your regex routines suffer this bug.
> These patches were not applied since I didn't think this would be a common
> problem. I simply set NO_REGEX=1 in my config.mak, since the compat/ regex
> routines don't suffer from this problem.

You also said:

  This is an RFC because:
   - A simple fix would be for me to put NO_REGEX=1 in my config.mak,
     since the compat/regex routines don't suffer this problem.
   - I suspect this bug is old enough that it will not affect many users.
   - I have not audited the other non-matching list expressions in
   - blame, grep and pickaxe all call regcomp() with the REG_NEWLINE
     flag, but get the regex from the user (eg from command line).

I think:

 - the second "this is old enough" assumption was broken again by
   Brian this week ;-)

 - the first "Use NO_REGEX if your regexp library is broken" is a
   reasonable thing to do; is this something we may want to throw
   into the platform specific section of the top-level Makefile?

 - among the fourth, "blame" and "grep" goes line by line, and even
   though pickaxe is primarily meant to take multi-line pattern, I
   do not think people give multi-line pattern when they use it in
   the regexp mode.  So I do not think they pose a real issue even
   though they get an arbitrary pattern from the user.

 - the third, combined with the fact that end user can define their
   own pattern, is a killer.  We cannot really afford to let broken
   regex library to break us.

I think a sensible way to go in the longer term, while we wait these
old regexp libraries die out, is to help people to avoid building
git without NO_REGEX on platforms where they need it.

Thanks for digging an old article.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to