I am setting a windows console to pass input of every character (as oppose to every line) by unsetting ENABLE_LINE_INPUT. A very weird byproduct is I get the cartage-return ('\r') charachter only after an additional keystroke.
This is the initialization code:
DWORD consoleModeIn;
HANDLE hStdin = GetStdHandle(STD_INPUT_HANDLE);
GetConsoleMode(hStdin, &consoleModeIn);
consoleModeIn = consoleModeIn & ~(ENABLE_ECHO_INPUT | ENABLE_LINE_INPUT);
SetConsoleMode(hStdin, consoleModeIn);
The reading:
size_t read_from_stdio(uint8_t* buf, size_t len)
{
size_t ret;
while ((0 == (ret = _read(_fileno(stdin), buf, len))) && (errno==EAGAIN));
return ret;
}
unsetting ENABLE_PROCESSED_INPUT doesn't either.
Any help is appreciated.
You're reading from the STDIN
file descriptor with the default text mode (for a tty). In text mode, the C runtime expects to read newlines as CRLF, which it translates to LF to facilitate cross-platform programs. To implement this it needs to read the next character after CR to look for CRLF sequences. Normally it's not an issue when reading from the console with line-input and processed-input modes enabled, since the console will translate CR to CRLF in its input buffer. However, by disabling line-input mode, you're also disabling the part of processed-input mode that makes the console convert CR to CRLF.
To work around this, you could set binary mode at startup via _setmode(_fileno(stdin), _O_BINARY)
. However, with binary-mode stdio you'll be limited to the console's current input codepage, which is still broken for codepage 65001 (UTF-8) in the latest Windows 10, so reading Unicode won't be possible. To get Unicode support without resorting to directly calling the Windows console API (e.g. ReadConsoleW
), you can instead use conio _getwch
.