https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81969
Bug ID: 81969
Summary: "el" escape sequence in coloring yields incorrect
message in some terminals
Product: gcc
Version: 6.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider a tst.c file:
int foo (void)
{
int x, xx;
return x + xx;
}
In a 80-column xterm, I get (where | represents the right border of the
terminal):
cventin% gcc-6 -Wall -c tst.c
|
tst.c: In function ‘foo’:
|
tst.c:4:12: warning: ‘x’ is used uninitialized in this function
[-Wuninitialize]|
return x + xx;
|
~~^~~~
|
tst.c:4:12: warning: ‘xx’ is used uninitialized in this function
[-Wuninitialize|
d]
|
i.e. the "d" of -Wuninitialized is missing in the first message.
In a 80-column rxvt, I get:
cventin% gcc-6 -Wall -c tst.c
|
tst.c: In function ‘foo’:
|
tst.c:4:12: warning: ‘x’ is used uninitialized in this function [-Wuninitialize
|
]
|
return x + xx;
|
~~^~~~
|
tst.c:4:12: warning: ‘xx’ is used uninitialized in this function
[-Wuninitialize|
d]
|
Here the "d" is replaced by a space.
In the xterm logs, I see a \E[K ("el" escape sequence, which clears to the end
of the line) after the first 80 characters. Thus this may be the same bug as in
grep: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15444
I quote:
The EL command (\E[K) is sent to clear the line. The VT100
terminal autowraps when the 81th character is received and the
EL command is not counted as a character. So if 80 characters
are received, it waits on the 80th character and the following
EL command erases characters from the current one to the end
of line (i.e. the last character on the line).
