Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxx> 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
userdiff.c
- 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html