On 2/11/26 10:28 AM, Thomas Dickey wrote:
On Mon, Feb 09, 2026 at 03:24:02PM +0100, Vincent Lefevre wrote:
mouseinterval(0);
// Don't mask any mouse events
mousemask(ALL_MOUSE_EVENTS | REPORT_MOUSE_POSITION, NULL);
printf("\033[?1003h\n"); // Makes the terminal report mouse movement events
There's no fflush here, so the program behavior is indeterminate.
For instance, this bug could account for the behavior you're reporting.
for (;;) {
int c = wgetch(stdscr);
// Exit the program on new line fed
if (c == '\n')
break;
char buffer[512];
size_t max_size = sizeof(buffer);
if (c == ERR) {
snprintf(buffer, max_size, "Nothing happened.");
}
else if (c == KEY_MOUSE) {
MEVENT event;
if (getmouse(&event) == OK) {
snprintf(buffer, max_size, "Mouse at row=%d, column=%d bstate=0x%08lx",
event.y, event.x, (unsigned long) event.bstate);
}
else {
snprintf(buffer, max_size, "Got bad mouse event.");
}
}
else {
snprintf(buffer, max_size, "Pressed key %d (%s)", c, keyname(c));
}
move(0, 0);
insertln();
addstr(buffer);
clrtoeol();
move(0, 0);
}
printf("\033[?1003l\n"); // Disable mouse movement events, as l = low
same bug here.
I'm pretty sure this is guaranteed to result in an `fflush`, since
`printf` here outputs to a terminal, and the C standard (not even POSIX,
the C standard itself) guarantees that stdout has at least
line-buffering (it may be unbuffered too, but that would be fine here
too) if connected to an interactive output device (e.g. a terminal),
meaning in these cases it will output the line given to `printf`
immediately since a line-buffering FILE flushes its buffer upon being
told to add a newline to it (although it is probably not very wise to
rely on this, and I would certainly recommend use of `fflush` here, the
behavior should be consistent in this particular case given the testing
appears to have been done with the output connected to a terminal)
