On Wed, Mar 08, 2000 at 06:58:18PM +0100, Mark Kettenis wrote: > Date: Wed, 8 Mar 2000 09:10:30 -0800 > From: "H . J . Lu" <[EMAIL PROTECTED]> > > It is almost entirely a Linux issue since we are the only one who > has the master copy of regex in our C library. > > What about the Hurd? > > I can add --enable-gdb-regex if it helps. > > If we decide to do so, could we then try to be consistent with other > GNU packages that already let the user choose between the regex > implementation distributed with that package, and the implementation > in the C library, and us --with(out)-included-regex? May I propose 1. Default is use to the master copy in the C library if available. 2. User can override it using --with-included-regex. 3. We can add a sanity check to see if the master copy is ok. If not, use the included one. I can implement 1 and 2. I don't care too much about 3. I am more interested in a working regex in my C library. > > See for example m4/regex.m4 in the snapshots of GNU text-utils on > alpha.gnu.org. > There is a problem. The testcase failed with glibc-2.1.3 because the master copy fixed a bug: 2000-01-18 Ulrich Drepper <[EMAIL PROTECTED]> * posix/regex.c (regex_compile): Return appropriate errors for unterminated brace expressions. Detect invalid characters in brace expressions. RE_SYNTAX_POSIX_EGREP sets both RE_NO_BK_BRACES and RE_INTERVALS. According to the comments in the heade file, that means `{...}' defines an interval and \{ and \} are literals. glibc 2.1.3 is correct to return an error for re_compile_pattern ("{1", 2, ®ex); since '}' is missing for interval. BTW, I just submit a patch for glibc to fix a bug when RE_INTERVALS is set and RE_NO_BK_BRACES is not set. glibc 2.1.3 failed re_compile_pattern ("\\{1", 2, ®ex); since `\{...\}' defines an interval now. H.J.