https://bugzilla.mindrot.org/show_bug.cgi?id=3534
--- Comment #7 from Damien Miller <[email protected]> --- Created attachment 3670 --> https://bugzilla.mindrot.org/attachment.cgi?id=3670&action=edit Used snmprintf() for window width handling Firstly, thanks a heap for the debugging and reproduction work you've done. It makes our lives a lot easier. It looks like what is happening is that snmprintf() (our UTF-8-aware string formatting function) can write more than win_size characters to the buffer. At first glance this shouldn't happen for two reasons: 1. file_len, which is used as the column limit to snmprintf() is less than win_size 2. The field with for the "%-*s" format string is passed as file_len too. Neither of these turns out to be an effective limit. For #2, this is the width of the field (i.e how much to pad) rather than the precision (where to chop). For #1, the column limit applies to the visual width of the string as displayed and not the number of characters used. These will differ if the string contains UTF-8 multibyte characters as this reproducer does. So strlen(buf) can easily exceed win_size for UTF-8 strings and this will lead to the negative snprintf() size later when we calculate is as "win_size - strlen(buf)". IMO the best solution to this is to let snmprintf() do more of the work in trying to hit win_size, as attempting to do it via strlen() is never going to work for UTF-8. This patch implements this, adjusting the first snmprintf() call to return how much padding we need to hit file_len. The padded string should be visually correct, but I added a final snmprintf() call to ensure that it's truncated in a UTF-8 safe way at win_size. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
