[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