aboutsummaryrefslogtreecommitdiff
path: root/libgloss/msp430
diff options
context:
space:
mode:
authorJohannes Schindelin <johannes.schindelin@gmx.de>2016-04-05 10:52:01 +0200
committerCorinna Vinschen <corinna@vinschen.de>2016-04-05 19:20:10 +0200
commit03ecfb9280ece68cce33c2f2002877d9a000ef1e (patch)
tree1ef17c7c1f7782bd23269a6ec623dd7654acc7fb /libgloss/msp430
parentcd84d1c2d06ad0a30f3aebb8ff86727df67ba0da (diff)
downloadnewlib-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