When grep is configured --with-included-regex, the following command fails to print the expected match:
printf '\351\n' |LC_ALL=fr_FR.iso88591 src/grep '[d-f]' You wouldn't notice on glibc-based systems, since the default there is to use the glibc-supplied regex code, which does make grep detect the match. However, on other systems (I noticed on OS X), configuration machinery detects that we have to resort to the included regex matcher, and there, the default build results in a grep binary that fails the new unibyte-bracket-expr test. Why? Because the included regcomp.c has two code paths: one for #if _LIBC (that is collating-sequence aware), and the other that ignores collation sequences. The former can be used only when building glibc itself, and is the path we require in order to handle this case. The latter code is what we get when compiling any place else. Since it's always been this way, I don't plan to attempt a work-around before the next release, and instead will probably arrange for that test to be skipped when grep is built with the included regex. Other ideas welcome, Jim
