https://bugzilla.novell.com/show_bug.cgi?id=329992#c21
--- Comment #21 from Petr Baudis 2007-11-27 10:27:49 MST ---
I see this in grep code:
if (!hard_LC_COLLATE) {
for (; c <= c2; c++)
setbit_case_fold (c, ccl);
} else {
/* POSIX locales are painful - leave the decision to libc */
char expr[6] = { '[', c, '-', c2, ']', '\0' };
regex_t re;
if (regcomp (&re, expr, case_fold ? REG_ICASE : 0) == REG_NOERROR) {
for (c = 0; c < NOTCHAR; ++c) {
char buf[2] = { c, '\0' };
regmatch_t mat;
if (regexec (&re, buf, 1, &mat, 0) == REG_NOERROR
&& mat.rm_so == 0 && mat.rm_eo == 1)
setbit_case_fold (c, ccl);
}
regfree (&re);
}
}
hard_LC_COLLATE is set if the locale is not C or POSIX (the comment is
confusing).
But yes, now I see that these calls in fact probably don't go to libc but to
lib/regex.c. But it seems to be used only conditionally? ltracing shows a lot
of libc calls.
It seems that grep prefers to use a separate mechanism for "rough matching" of
lines and then uses regexp matching only on the line candidates, though I'm not
sure if I understand the code correctly. Anyway, my Gentoo used to exhibit this
bug but now it doesn't anymore (or maybe it's overriden by another bug because
coloring works real strange here now), so I don't have any system where I could
reproduce it. Did anyone else manage to reproduce this in-house? On what
machine?
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.