Since `c` there is a result of evaluating `TO_SPECIAL` macros it may be only one
of the following three things:
1. K_SPECIAL
2. K_ZERO (note: not KS_ZERO)
3. negative integer resulting from evaluating TERMCAP2KEY macro.
All variants here are negative and thus fail next !IS_SPECIAL(c) check (negative
is special). If `c` was really NUL it would fall into the `!IS_SPECIAL(c)` block
and use whatever character is third in `<80>{a}{b}` combo. For `<Nul>` it is
X (`<80><ff>X`).
Some calculation show that with the current setup there will not be enough bytes
occupied for that, barring the case of malicious translation. Still should be
possible to have array overrun with specially crafted translation.
1. Don't check elapsed time in children_kill_cb(), it's already implied
by the start-time of the timer itself.
2. Restart timer from children_kill_cb() for PTY jobs, to send SIGKILL
after SIGTERM. There is an edge case where SIGKILL might follow
SIGTERM too quickly, if jobstop() is called near the 2-second timer
window. But this edge case is not worth code complication.
Before f31c26f1af the timer was used to try SIGTERM *and* SIGKILL, so
a repeating timer was needed. After f31c26f1af process_stop() sends
SIGTERM immediately, and the timer only sends SIGKILL.
So we don't need a repeating timer.
- Simplifies the logic: don't need to call uv_timer_stop() explicitly.
- Avoids a problem: if process_stop() is called more than once in the
2-second window, the first on_process_exit() would call
uv_timer_stop() which stops the timer for all stopped processes.
children_kill_cb() is racey. One obvious problem is that
process_close_handles() is *queued* by on_process_exit(), so when
children_kill_cb() is invoked, the dead process might still be in the
`loop->children` list. If the OS already reclaimed the dead PID, Nvim
may try to SIGKILL it.
Avoid that by checking `proc->status`.
Vim doesn't have this problem because it doesn't attempt to kill
processes that ignored SIGTERM after a timeout.
closes#8269
I failed to deduce why analyzer thinks E882 may not be triggered, though
conditions for triggering it are strange: it would trigger E882 only in the
single case “function returned non-number”. Cases “function thrown exception”,
or “built-in sorter encountered error” will neither yield E882 nor stop
sort()/uniq().
Note though that searching test code revealed that neither E702 nor E882 are not
tested anywhere.
Fixes#6890 by reading from the Windows console input buffer after
stdin has been closed.
Vim defines HAVE_DUP for Windows and does the close-dup dance[1]:
close(0);
dup(2);
which always fails, then falls back to reading from the Windows console
input buffer[2].
[1] e7499ddc33/src/fileio.c (L2397-L2398)
[2] e7499ddc33/src/os_win32.c (L1703-L1714)
* Reading from stdin on Windows is fixed in the same way as it was in
#8267.
* The file_read function was returning without filling the
destination buffer when it was called with a non-blocking file
descriptor.
