[hackers] [st] fix for incorrect (partial) written sequences when libc wcwidth() == -1 || Hiltjo Posthuma

[git]

commit 8211e36d281990a39db1853bcd454ac59e53d521
Author:     Hiltjo Posthuma <hil...@codemadness.org>
AuthorDate: Sat May 9 13:56:28 2020 +0200
Commit:     Hiltjo Posthuma <hil...@codemadness.org>
CommitDate: Sat May 9 14:07:52 2020 +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: czark...@gmail.com <czark...@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.

diff --git a/st.c b/st.c
index c161497..5d4054f 100644
--- 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))