Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unicode character ſ is matched as itself and as 's.' #14294

Open
diffsetter opened this issue Mar 25, 2024 · 5 comments · May be fixed by #14756
Open

Unicode character ſ is matched as itself and as 's.' #14294

diffsetter opened this issue Mar 25, 2024 · 5 comments · May be fixed by #14756
Labels

Comments

@diffsetter
Copy link

Steps to reproduce

  1. Open a utf8 encoded file in vim containing the line "Die Gleichheit fordert das Nachdenken heraus durch Fragen, die ſich daran knüpfen und nicht ganz leicht zu beantworten ſind."
  2. use :set ignorecase
  3. replace the character ſ by s using :%s/\%u017F/s/g

Expected behaviour

The two occurrences of 'ſ' will be replaced by 's' resulting in "Die Gleichheit fordert das Nachdenken heraus durch Fragen, die sich daran knüpfen und nicht ganz leicht zu beantworten sind." However, the actual result is "Die Gleichheit fordert dasNachdenken herausdurch Fragen, die sich daran knüpfen und nicht ganz leicht zu beantworten sind.", i.e., the two original s characters together with the following character are also replaced by 's' as if I had used the command :%s/s./s/g. See also this discussion.

Version of Vim

9.1.151 but also older like 8.0

Environment

system: x86_64 GNU/Linux
terminal: konsole, linux
$TERM: linux, xterm-256color
$LANG: de_DE.UTF-8, en_GB.UTF-8, C.UTF-8

Logs and stack traces

No response

@diffsetter diffsetter added the bug label Mar 25, 2024
@chrisbra
Copy link
Member

hm, it works with :set regexpengine=1

@diffsetter
Copy link
Author

hm, it works with :set regexpengine=1

Indeed, it does. But does that mean it's not a bug? I didn't know that option. The help file says: "Note that when using the NFA engine [the one that must have been chosen by vim automatically in this case] and the pattern contains something that is not supported the pattern will not match…" But here something is matched that shouldn't have been matched.

@RestorerZ
Copy link
Contributor

It kind of reminds me of this. issues #12579

@chrisbra
Copy link
Member

yes and also related: #13682

chrisbra added a commit to chrisbra/vim that referenced this issue Apr 6, 2024
…ngle byte char

When the regexp engine compares two utf-8 codepoints case insensitively
it may match an adjacent character, because it assumes it can step over
as many bytes as the pattern contains.

Let's consider the pattern 'ſ' and the string 's '. When comparing and
ignoring case, the single character 's' matches, and since it matches
Vim will try to step over the match (by the amount of bytes of the
pattern), assuming that since it matches, the length of both strings is
the same.

However in that case, it should only step over the single byte
value 's' by 1 byte and try to start matching after it again. So for the
backtracking engine we need to ensure:
- we try to match the correct length for the pattern and the text
- in case of a match, we step over it correctly

For the NFA engine, it basically already handles it already. Here we
just need to make sure, that find_match_text is only called if
prog->match_text is actually not only NULL but also doesn't point to 0x0
(NUL).

fixes: vim#14294

Signed-off-by: Christian Brabandt <cb@256bit.org>
@chrisbra
Copy link
Member

chrisbra commented Apr 6, 2024

I checked it and I think I found the issue. However, I have a question. Can I assume correctly, that 'ſ' should match the lower case 's' if ignoring case?

chrisbra added a commit to chrisbra/vim that referenced this issue Apr 8, 2024
…te char

When the regexp engine compares two utf-8 codepoints case insensitively
it may match an adjacent character, because it assumes it can step over
as many bytes as the pattern contains.

This however is not necessarily true because of case-folding, a
multi-byte UTF-8 character can be considered equal to some single-byte
value.

Let's consider the pattern 'ſ' and the string 's'. When comparing and
ignoring case, the single character 's' matches, and since it matches
Vim will try to step over the match (by the amount of bytes of the
pattern), assuming that since it matches, the length of both strings is
the same.

However in that case, it should only step over the single byte
value 's' by 1 byte and try to start matching after it again. So for the
backtracking engine we need to ensure:
- we try to match the correct length for the pattern and the text
- in case of a match, we step over it correctly

The same thing can happen for the NFA engine, when skipping to the next
character to test for a match. We are skipping over the regstart
pointer, however we do not consider the case that because of
case-folding we may need to adjust the number of bytes to skip over. So
this needs to be adjusted in find_match_text() as well.

A related issue turned out, when prog->match_text is actually empty. In
that case we should try to find the next match and skip this condition.

fixes: vim#14294

Signed-off-by: Christian Brabandt <cb@256bit.org>
chrisbra added a commit to chrisbra/vim that referenced this issue Apr 8, 2024
…te char

When the regexp engine compares two utf-8 codepoints case insensitively
it may match an adjacent character, because it assumes it can step over
as many bytes as the pattern contains.

This however is not necessarily true because of case-folding, a
multi-byte UTF-8 character can be considered equal to some single-byte
value.

Let's consider the pattern 'ſ' and the string 's'. When comparing and
ignoring case, the single character 's' matches, and since it matches
Vim will try to step over the match (by the amount of bytes of the
pattern), assuming that since it matches, the length of both strings is
the same.

However in that case, it should only step over the single byte
value 's' by 1 byte and try to start matching after it again. So for the
backtracking engine we need to ensure:
- we try to match the correct length for the pattern and the text
- in case of a match, we step over it correctly

The same thing can happen for the NFA engine, when skipping to the next
character to test for a match. We are skipping over the regstart
pointer, however we do not consider the case that because of
case-folding we may need to adjust the number of bytes to skip over. So
this needs to be adjusted in find_match_text() as well.

A related issue turned out, when prog->match_text is actually empty. In
that case we should try to find the next match and skip this condition.

fixes: vim#14294

Signed-off-by: Christian Brabandt <cb@256bit.org>
chrisbra added a commit to chrisbra/vim that referenced this issue Apr 9, 2024
…te char

When the regexp engine compares two utf-8 codepoints case insensitively
it may match an adjacent character, because it assumes it can step over
as many bytes as the pattern contains.

This however is not necessarily true because of case-folding, a
multi-byte UTF-8 character can be considered equal to some single-byte
value.

Let's consider the pattern 'ſ' and the string 's'. When comparing and
ignoring case, the single character 's' matches, and since it matches
Vim will try to step over the match (by the amount of bytes of the
pattern), assuming that since it matches, the length of both strings is
the same.

However in that case, it should only step over the single byte
value 's' by 1 byte and try to start matching after it again. So for the
backtracking engine we need to ensure:
- we try to match the correct length for the pattern and the text
- in case of a match, we step over it correctly

The same thing can happen for the NFA engine, when skipping to the next
character to test for a match. We are skipping over the regstart
pointer, however we do not consider the case that because of
case-folding we may need to adjust the number of bytes to skip over. So
this needs to be adjusted in find_match_text() as well.

A related issue turned out, when prog->match_text is actually empty. In
that case we should try to find the next match and skip this condition.

fixes: vim#14294

Signed-off-by: Christian Brabandt <cb@256bit.org>
zeertzjq added a commit to zeertzjq/neovim that referenced this issue Apr 9, 2024
Problem:  Regex engines do not handle case-folding well
Solution: Correctly calculate byte length of characters to skip

When the regexp engine compares two utf-8 codepoints case insensitively
it may match an adjacent character, because it assumes it can step over
as many bytes as the pattern contains.

This however is not necessarily true because of case-folding, a
multi-byte UTF-8 character can be considered equal to some single-byte
value.

Let's consider the pattern 'ſ' and the string 's'. When comparing and
ignoring case, the single character 's' matches, and since it matches
Vim will try to step over the match (by the amount of bytes of the
pattern), assuming that since it matches, the length of both strings is
the same.

However in that case, it should only step over the single byte
value 's' so by 1 byte and try to start matching after it again. So for the
backtracking engine we need to ensure:
- we try to match the correct length for the pattern and the text
- in case of a match, we step over it correctly

The same thing can happen for the NFA engine, when skipping to the next
character to test for a match. We are skipping over the regstart
pointer, however we do not consider the case that because of
case-folding we may need to adjust the number of bytes to skip over. So
this needs to be adjusted in find_match_text() as well.

A related issue turned out, when prog->match_text is actually empty. In
that case we should try to find the next match and skip this condition.

fixes: vim/vim#14294
closes: vim/vim#14433

vim/vim@7a27c10

Co-authored-by: Christian Brabandt <cb@256bit.org>
zeertzjq added a commit to neovim/neovim that referenced this issue Apr 9, 2024
…28259)

Problem:  Regex engines do not handle case-folding well
Solution: Correctly calculate byte length of characters to skip

When the regexp engine compares two utf-8 codepoints case insensitively
it may match an adjacent character, because it assumes it can step over
as many bytes as the pattern contains.

This however is not necessarily true because of case-folding, a
multi-byte UTF-8 character can be considered equal to some single-byte
value.

Let's consider the pattern 'ſ' and the string 's'. When comparing and
ignoring case, the single character 's' matches, and since it matches
Vim will try to step over the match (by the amount of bytes of the
pattern), assuming that since it matches, the length of both strings is
the same.

However in that case, it should only step over the single byte
value 's' so by 1 byte and try to start matching after it again. So for the
backtracking engine we need to ensure:
- we try to match the correct length for the pattern and the text
- in case of a match, we step over it correctly

The same thing can happen for the NFA engine, when skipping to the next
character to test for a match. We are skipping over the regstart
pointer, however we do not consider the case that because of
case-folding we may need to adjust the number of bytes to skip over. So
this needs to be adjusted in find_match_text() as well.

A related issue turned out, when prog->match_text is actually empty. In
that case we should try to find the next match and skip this condition.

fixes: vim/vim#14294
closes: vim/vim#14433

vim/vim@7a27c10

Co-authored-by: Christian Brabandt <cb@256bit.org>
@chrisbra chrisbra reopened this Apr 10, 2024
chrisbra added a commit to chrisbra/vim that referenced this issue Apr 10, 2024
…te char

When the regexp engine compares two utf-8 codepoints case insensitively
it may match an adjacent character, because it assumes it can step over
as many bytes as the pattern contains.

This however is not necessarily true because of case-folding, a
multi-byte UTF-8 character can be considered equal to some single-byte
value.

Let's consider the pattern 'ſ' and the string 's'. When comparing and
ignoring case, the single character 's' matches, and since it matches
Vim will try to step over the match (by the amount of bytes of the
pattern), assuming that since it matches, the length of both strings is
the same.

However in that case, it should only step over the single byte
value 's' by 1 byte and try to start matching after it again. So for the
backtracking engine we need to ensure:
- we try to match the correct length for the pattern and the text
- in case of a match, we step over it correctly

The same thing can happen for the NFA engine, when skipping to the next
character to test for a match. We are skipping over the regstart
pointer, however we do not consider the case that because of
case-folding we may need to adjust the number of bytes to skip over. So
this needs to be adjusted in find_match_text() as well.

A related issue turned out, when prog->match_text is actually empty. In
that case we should try to find the next match and skip this condition.

Note: this breaks Mail and CSS Syntax highlighting and CI on FreeBSD/MacOS
vim#14487 and
https://groups.google.com/d/msgid/vim_dev/CAJkCKXtui%3DDTWx9eV8Dbs19XoFL9b63ObSNXWCRvLsEZCB6yfw%40mail.gmail.com.

fixes: vim#14294

Signed-off-by: Christian Brabandt <cb@256bit.org>
chrisbra added a commit to chrisbra/vim that referenced this issue May 12, 2024
…te char

When the regexp engine compares two utf-8 codepoints case insensitively
it may match an adjacent character, because it assumes it can step over
as many bytes as the pattern contains.

This however is not necessarily true because of case-folding, a
multi-byte UTF-8 character can be considered equal to some single-byte
value.

Let's consider the pattern 'ſ' and the string 's'. When comparing and
ignoring case, the single character 's' matches, and since it matches
Vim will try to step over the match (by the amount of bytes of the
pattern), assuming that since it matches, the length of both strings is
the same.

However in that case, it should only step over the single byte
value 's' by 1 byte and try to start matching after it again. So for the
backtracking engine we need to ensure:
- we try to match the correct length for the pattern and the text
- in case of a match, we step over it correctly

The same thing can happen for the NFA engine, when skipping to the next
character to test for a match. We are skipping over the regstart
pointer, however we do not consider the case that because of
case-folding we may need to adjust the number of bytes to skip over. So
this needs to be adjusted in find_match_text() as well.

A related issue turned out, when prog->match_text is actually empty. In
that case we should try to find the next match and skip this condition.

Note: this breaks Mail and CSS Syntax highlighting and CI on FreeBSD/MacOS
vim#14487 and
https://groups.google.com/d/msgid/vim_dev/CAJkCKXtui%3DDTWx9eV8Dbs19XoFL9b63ObSNXWCRvLsEZCB6yfw%40mail.gmail.com.

fixes: vim#14294

Signed-off-by: Christian Brabandt <cb@256bit.org>
chrisbra added a commit to chrisbra/vim that referenced this issue May 12, 2024
…te char

When the regexp engine compares two utf-8 codepoints case insensitively
it may match an adjacent character, because it assumes it can step over
as many bytes as the pattern contains.

This however is not necessarily true because of case-folding, a
multi-byte UTF-8 character can be considered equal to some single-byte
value.

Let's consider the pattern 'ſ' and the string 's'. When comparing and
ignoring case, the single character 's' matches, and since it matches
Vim will try to step over the match (by the amount of bytes of the
pattern), assuming that since it matches, the length of both strings is
the same.

However in that case, it should only step over the single byte
value 's' by 1 byte and try to start matching after it again. So for the
backtracking engine we need to ensure:
- we try to match the correct length for the pattern and the text
- in case of a match, we step over it correctly

The same thing can happen for the NFA engine, when skipping to the next
character to test for a match. We are skipping over the regstart
pointer, however we do not consider the case that because of
case-folding we may need to adjust the number of bytes to skip over. So
this needs to be adjusted in find_match_text() as well.

A related issue turned out, when prog->match_text is actually empty. In
that case we should try to find the next match and skip this condition.

Note: this breaks Mail and CSS Syntax highlighting and CI on FreeBSD/MacOS
vim#14487 and
https://groups.google.com/d/msgid/vim_dev/CAJkCKXtui%3DDTWx9eV8Dbs19XoFL9b63ObSNXWCRvLsEZCB6yfw%40mail.gmail.com.

fixes: vim#14294

Signed-off-by: Christian Brabandt <cb@256bit.org>
chrisbra added a commit to chrisbra/vim that referenced this issue May 12, 2024
…te char

This is v2 of v9.1.296, but still draft to see if this still breaks.

When the regexp engine compares two utf-8 codepoints case insensitively it may
match an adjacent character, because it assumes it can step over as many bytes
as the pattern contains.

This however is not necessarily true because of case-folding, a multi-byte
UTF-8 character can be considered equal to some single-byte value.

Let's consider the pattern 'ſ' and the string 's'. When comparing and ignoring
case, the single character 's' matches, and since it matches Vim will try to
step over the match (by the amount of bytes of the pattern), assuming that
since it matches, the length of both strings is the same.

However in that case, it should only step over the single byte value 's' by 1
byte and try to start matching after it again. So for the backtracking engine
we need to ensure:
- we try to match the correct length for the pattern and the text
- in case of a match, we step over it correctly

There is one tricky thing for the backtracing engine. We also need to calculate
correctly the number of bytes to compare the 2 different utf-8 strings s1 and
s2. So we will count the number of characters in s1 that the byte len
specified. Then we count the number of bytes to step over the same number of
characters in string s2 and then we can correctly compare the 2 utf-8 strings.

A similar thing can happen for the NFA engine, when skipping to the next
character to test for a match. We are skipping over the regstart pointer,
however we do not consider the case that because of case-folding we may need to
adjust the number of bytes to skip over. So this needs to be adjusted in
find_match_text() as well.

A related issue turned out, when prog->match_text is actually empty. In that
case we should try to find the next match and skip this condition.

Note: this breaks Mail and CSS Syntax highlighting and CI on FreeBSD/MacOS
vim#14487 and
https://groups.google.com/d/msgid/vim_dev/CAJkCKXtui%3DDTWx9eV8Dbs19XoFL9b63ObSNXWCRvLsEZCB6yfw%40mail.gmail.com.

fixes: vim#14294

Signed-off-by: Christian Brabandt <cb@256bit.org>
chrisbra added a commit to chrisbra/vim that referenced this issue May 12, 2024
…te char

This is v2 of v9.1.296, but still draft to see if this still breaks.

When the regexp engine compares two utf-8 codepoints case insensitively it may
match an adjacent character, because it assumes it can step over as many bytes
as the pattern contains.

This however is not necessarily true because of case-folding, a multi-byte
UTF-8 character can be considered equal to some single-byte value.

Let's consider the pattern 'ſ' and the string 's'. When comparing and ignoring
case, the single character 's' matches, and since it matches Vim will try to
step over the match (by the amount of bytes of the pattern), assuming that
since it matches, the length of both strings is the same.

However in that case, it should only step over the single byte value 's' by 1
byte and try to start matching after it again. So for the backtracking engine
we need to ensure:
- we try to match the correct length for the pattern and the text
- in case of a match, we step over it correctly

There is one tricky thing for the backtracing engine. We also need to calculate
correctly the number of bytes to compare the 2 different utf-8 strings s1 and
s2. So we will count the number of characters in s1 that the byte len
specified. Then we count the number of bytes to step over the same number of
characters in string s2 and then we can correctly compare the 2 utf-8 strings.

A similar thing can happen for the NFA engine, when skipping to the next
character to test for a match. We are skipping over the regstart pointer,
however we do not consider the case that because of case-folding we may need to
adjust the number of bytes to skip over. So this needs to be adjusted in
find_match_text() as well.

A related issue turned out, when prog->match_text is actually empty. In that
case we should try to find the next match and skip this condition.

Note: this breaks Mail and CSS Syntax highlighting and CI on FreeBSD/MacOS
vim#14487 and
https://groups.google.com/d/msgid/vim_dev/CAJkCKXtui%3DDTWx9eV8Dbs19XoFL9b63ObSNXWCRvLsEZCB6yfw%40mail.gmail.com.

fixes: vim#14294

Signed-off-by: Christian Brabandt <cb@256bit.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants