Re: svn commit: r352558 - head/usr.bin/top

From: Yuri Pankov <yuripv_at_yuripv.dev>
Date: Fri, 10 Jul 2020 21:05:47 +0300
Steve Wills wrote:
> On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote:
>>> Author: daichi
>>> Date: Fri Sep 20 17:37:23 2019
>>> New Revision: 352558
>>> URL:
>>> https://svnweb.freebsd.org/changeset/base/352558
>>>
>>>
>>> Log:
>>>    top(1): support multibyte characters in command names (ARGV array)
>>>    depending on locale.
>>>     - add setlocale()
>>>     - remove printable() function
>>>     - add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display
>>>       non-printable characters that do not use C-style backslash 
>>> sequences
>>>       in three digit octal sequence, or remove it
>>>    This change allows multibyte characters to be displayed according to
>>>    locale. If it is recognized as a non-display character according 
>>> to the
>>>    locale, it is displayed in three digit octal sequence.
>>>
>>
>> Initially picking on tab characters as an example of what is
>> probably a somewhat broader issue . . .
>>
>> Ever since this change, characters like tabs that do not fit
>> in the next character cell when output, but for which they
>> are !isprintable(...), now mess up the top display. Again
>> using tab as an example: line wrapping from the text having
>> been shifted over by more than one character cell. top does
>> not track the line wrapping result in how it decides what
>> to output for the following display updates.
>>
> 
> Apologies for the way late reply here, but I just now bothered tracking 
> this down. This commit seems to be the cause of some corruption I'm 
> seeing in long running top(1) as well. As Mark mentions, if I use "hh" 
> it clears up. Should I open a bugzilla bug? I can share screenshots of 
> the corruption, such as:
> 
> https://i.imgur.com/Xqlwf9h.png
> https://i.imgur.com/Jv0d5NU.png

Does removing VIS_SAFE fixes the issue for you?

As for original Mark's report (which I missed), removing isprintable() 
doesn't look wrong as vis(3) should take of its functionality (and in 
multibyte-aware way).

Also, is there an easy way to reproduce this?
Received on Fri Jul 10 2020 - 16:05:54 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:24 UTC