diff options
author | Johannes Schindelin <johannes.schindelin@gmx.de> | 2016-04-05 10:52:01 +0200 |
---|---|---|
committer | Corinna Vinschen <corinna@vinschen.de> | 2016-04-05 19:20:10 +0200 |
commit | 03ecfb9280ece68cce33c2f2002877d9a000ef1e (patch) | |
tree | 1ef17c7c1f7782bd23269a6ec623dd7654acc7fb /libgloss/msp430 | |
parent | cd84d1c2d06ad0a30f3aebb8ff86727df67ba0da (diff) | |
download | newlib-03ecfb9280ece68cce33c2f2002877d9a000ef1e.zip newlib-03ecfb9280ece68cce33c2f2002877d9a000ef1e.tar.gz newlib-03ecfb9280ece68cce33c2f2002877d9a000ef1e.tar.bz2 |
Be truthful about reporting whether readahead is available
In 7346568 (Make requested console reports work, 2016-03-16), code was
introduced to report the current cursor position. It works by using a
pointer that either points to the next byte in the readahead buffer, or
to a NUL byte if the buffer is depleted, or the pointer is NULL.
These conditions are heeded in the fhandler_console::read() method, but
the condition that the pointer can point at the end of the readahead
buffer was not handled properly in the get_cons_readahead_valid()
method.
This poses a problem e.g. in Git for Windows (which uses a slightly
modified MSYS2 runtime which is in turn a slightly modified Cygwin
runtime) when vim queries the cursor position and immediately goes on to
read console input, erroneously thinking that the readahead buffer is
valid when it is already depleted instead. This condition results in an
apparent freeze that can be helped only by pressing keys repeatedly.
The full Git for Windows bug report is here:
https://github.com/git-for-windows/git/issues/711
Let's just teach the get_cons_readahead_valid() method to handle a
depleted readahead buffer correctly.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Diffstat (limited to 'libgloss/msp430')
0 files changed, 0 insertions, 0 deletions