 |
fix for incorrect (partial) written sequences when libc wcwidth() == -1 - st - … |
 |
git clone git://git.suckless.org/st |
 |
Log |
|
Files |
|
Refs |
|
README |
|
LICENSE |
|
--- |
|
commit 8211e36d281990a39db1853bcd454ac59e53d521 |
|
parent 87545c612e8ab6e7cd1ef38e2355d0cb86df79f2 |
|
Author: Hiltjo Posthuma <[email protected]> |
|
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: [email protected] <[email protected]> |
|
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(-) |
|
--- |
|
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)) |
