https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66318
--- Comment #6 from Keith Thompson <Keith.S.Thompson at gmail dot com> --- Thanks to this: http://undeadly.org/cgi?action=article&sid=20160308204011 I've now constructed a case where compiling a malicious source file can cause xterm to freeze. The source file uses a UTF-8 character in a file name. The problem occurs when xterm is run without UTF-8 support. The first byte of the UTF-8 character happens to be the "application program command" command, which causes subsequent input to be ignored until the xterm receives the "string terminator" byte '\234'. To reproduce the problem: 1. Run "xterm -lc +u8" 2. In that xterm, run "/bin/sh". (The bash shell sends some control codes when it prints a prompt; /bin/sh typically doesn't. You might need to use some other shell.) 3. In that shell: "unset LC_ALL LC_CTYPE LANG". 4. printf '#line __LINE__ "\303\237"\n#error "Kaboom"\n' > kaboom.c 5. gcc -c kaboom.c In a UTF-8 environment, this simply prints an error message that includes a Unicode LATIN SMALL LETTER SHARP S as the file name: $ gcc -c kaboom.c ß:1:2: error: #error "Kaboom" In an ASCII environment, as above, the xterm prints a LATIN CAPITAL LETTER A WITH TILDE and freezes. (You can recover by doing a soft reset via the middle-click mouse menu.)
