Long command lines messing up top's process list display: -r335850 related (in part)?

I've been looking into why I see top sometimes overwriting
text across multiple lines when watching buildworld
activity (for example). An example (from a 200 column, 70
lines display window) is:

21041 root         74    0    11M  2380K CPU27   27   0:01  41.60% sed \nbj/amd6/ [TDW] / {\n.amd64/usr/s/:.* [TDW] / /\nmp/usr/bin/c++ w /tmp/_symbol_.uQMlIJnU\nn-freebsd13.0 d\nit-ob}\ndisab/ U / {\
n0981 root      s/:52 U / /\n 20M  6156K pipewr   2   0:00  15.02% nm -go Analysis/AliasAnalysis.o Analysis/AliasAnalysisEvaluator.o Analysis/AliasAnalysisSummary.o Analysis/AliasSetTracker.o Analysi
21037 root         52    0    11M  2512K piperd   1   0:00   0.21% tsort -q
21036 root         52    0    12M  3240K wait    22   0:00   0.32% /bin/sh - /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/sbin/lorder Analysis/AliasAnalysis.o Analysis/AliasAna

(The lorder/tsort/nm/sed sequence and its sed line might
not be the only such context. But it seems to be a primary
example for buildworld context.) The example is more
readable than they are sometimes but I think makes clear
the issue. You can see where top updates only parts of a
line, not expecting other text to have changed --yet they
have changed.

(Also: The context is ssh-terminal sessions over ethernet,
not error prone serial-line based terminal sessions.)

I end up forcing top to rewrite its display from scratch
to get rid of accumulated stray text. (hh, toggling the
type of display and back.)


Looking around I ran into:

QUOTE
Revision 335850 - (view) (download) (annotate) - [select for diffs] 
Modified Sun Jul 1 19:44:29 2018 UTC (17 months, 3 weeks ago) by eadler 
File length: 41331 byte(s) 
Diff to previous 335836
top(1): permit infinite length for command

There isn't any need to limit the size of the screen. Utilities like
'less -S' don't have a (meaningful) limit anyways.  This also makes the
way to dynamically changing the column widths based on the screen width.
END QUOTE

and it seems to have removed what originally stopped the
sbuf for a line from outputting too much text for the space
available on the line: it previously accounted for the prior
columns already put to use vs. screen_width in use at the
time and used the count of what space was left.

(Some later revisions are related but all after -r335850
looked like they did not deal with limiting to the space
available after the other columns at any stage that I found.
In essence I'm trying to ask based on where it looks like
the issue might have started.)

Was some other part of the code supposed to prevent lines
that can not fit the space from overwriting other text 
from other processes in the list? It seems to be overwriting
in a way that top does not track and does put back the other
line's own text?

(Of course, I may just not have found what was to deal with
such, I'm not a top expert.)

A related issue for the overall problem is . . .

I also ran into the removal of printable mixed with the use of:

				strvisx(dst, src,
				    MIN(strlen(src), len),
				    VIS_NL | VIS_CSTYLE | VIS_OCTAL | VIS_SAFE);


When I looked up VIS_SAFE, I found:

QUOTE
     VIS_SAFE	 Only encode "unsafe" characters.  Unsafe means	control	char-
		 acters	which may cause	common terminals to perform unexpected
		 functions.  Currently this form allows	space, tab, newline,
		 backspace, bell, and return --	in addition to all graphic
		 characters -- unencoded.
END QUOTE

For tab, for example, sent "unencoded": Might this lead
the cursor being out of the expected place for whatever
text is to follow? (VIS_TAB is not used. The VIS_NL
seems to override VIS_SAFE for newlines.) But it looks
to me like backspace, bell, and return sent "unencoded"
would not end up with the cursor where top expects it
to end up for figuring out what to do next for updating
the display, likely resulting in a messed up display as
well.

This change is more recent than -r335850.


I may not have found all contributing changes for the
display not updating correctly. But those two are what
I've noticed looking around as possible contributors.

I will note that my context is not a good test for
UTF-8 handling and the like, except as the case of
looks like ASCII with:

# locale
LANG=
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=

So the coverage by my activity is limited, and on
the simpler side.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)