Re: A patch for gnu-regex

["H . J . Lu" <hjl at lucon dot org>]

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" <hjl@lucon.org>
> 
>    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  <drepper@cygnus.com>

	* 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, &regex);

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, &regex);

since `\{...\}' defines an interval now.


H.J.