fix for incorrect (partial) written sequences when libc wcwidth() == -1 - st - Personal fork of st
(HTM) git clone git://git.drkhsh.at/st.git
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) README
(DIR) LICENSE
---
(DIR) commit 8211e36d281990a39db1853bcd454ac59e53d521
(DIR) parent 87545c612e8ab6e7cd1ef38e2355d0cb86df79f2
(HTM) Author: Hiltjo Posthuma <hiltjo@codemadness.org>
Date: Sat, 9 May 2020 13:56:28 +0200
fix for incorrect (partial) written sequences when libc wcwidth() == -1
Fix an issue with incorrect (partial) written sequences when libc wcwidth() ==
-1. The sequence is updated to on wcwidth(u) == -1:
c = "\357\277\275"
but len isn't.
A way to reproduce in practise:
* st -o dump.txt
* In the terminal: printf '\xcd\xb8'
- This is codepoint 888, on OpenBSD it reports wcwidth() == -1.
- Quit the terminal.
- Look in dump.txt (partial written sequence of "UTF_INVALID").
This was introduced in:
" commit 11625c7166b7e4dad414606227acec2de1c36464
Author: czarkoff@gmail.com <czarkoff@gmail.com>
Date: Tue Oct 28 12:55:28 2014 +0100
Replace character with U+FFFD if wcwidth() is -1
Helpful when new Unicode codepoints are not recognized by libc."
Change:
Remove setting the sequence. If this happens to break something, another
solution could be setting len = 3 for the sequence.
Diffstat:
M st.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
---
(DIR) diff --git a/st.c b/st.c
@@ -2312,10 +2312,8 @@ tputc(Rune u)
width = len = 1;
} else {
len = utf8encode(u, c);
- if (!control && (width = wcwidth(u)) == -1) {
- memcpy(c, "\357\277\275", 4); /* UTF_INVALID */
+ if (!control && (width = wcwidth(u)) == -1)
width = 1;
- }
}
if (IS_SET(MODE_PRINT))