[Bug 3534] probable underflow calculating display width of file name

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3534

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
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.