GNU bug report logs - #4209
23.1; Emacs 23.1 regression in re-search-forward

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 4209 <at> debbugs.gnu.org, cyd <at> stupidchicken.com
Subject: bug#4209: 23.1; Emacs 23.1 regression in re-search-forward
Date: Wed, 27 Jan 2010 09:34:38 -0500

>> > Could you try to investigate Bug#4209?
>> Ok, I'll work on it.
> I fixed it as below.

> === modified file 'src/regex.c'
> --- src/regex.c	2010-01-13 08:35:10 +0000
> +++ src/regex.c	2010-01-27 03:57:03 +0000
> @@ -4083,8 +4083,7 @@
>  		     the corresponding multibyte character.  */
>  		  int c = RE_CHAR_TO_MULTIBYTE (p[1]);
 
> -		  if (! CHAR_BYTE8_P (c))
> -		    fastmap[CHAR_LEADING_CODE (c)] = 1;
> +		  fastmap[CHAR_LEADING_CODE (c)] = 1;
>  		}
>  	    }
>  	  break;

> But, first of all, I don't know (remember) why there was this check:

>    if (! CHAR_BYTE8_P (c))

> I may have overlooked something.  Stefan, could you please
> confirm that the above change is correct?

The preceding comment keeps me puzzled.  I thought that we only ever
matched re_patterns and buffers of the same multibyteness, i.e. if
a unibyte regexp is matched against a multibyte buffer it should first
be turned into a multibyte regexp and then re_compiled, so the case of:

		  /* For the case of matching this unibyte regex
		     against multibyte, we must set a leading code of
		     the corresponding multibyte character.  */

should never happen in analyse_first.  Yet, if your patch fixes the bug,
that indicates that apparently it *does* happen.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.