bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#4209: 23.1; Emacs 23.1 regression in re-search-forward


From: Stefan Monnier
Subject: bug#4209: 23.1; Emacs 23.1 regression in re-search-forward
Date: Wed, 27 Jan 2010 09:34:38 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux)

>> > 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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]