On Tue, Jul 21, 2026 at 09:01:13AM -0400, Mouse wrote: > > I'm told this was fixed (almost the same the way I fixed it) in the > main NetBSD tree in...2010, I think it was. >
Ah, good to know. > > If you can absolutely show that we are referencing uninitialised data > > then sbutmit a PR and I will be happy to have a look. > > If you think a PR against 5.2 will do anything useful, sure. > > I'm inclined to doubt it. > I'm inclined to agree with you. > > As a thought, I wonder if you are making things complicated for > > yourself, you could split your program into two cooperating > > processes, one that handles the async interactions with the hardware > > and the other handles the UI. > > The UI process would have to handle some async stuff from the > hardware-interface process, though, so I'm not sure it would help all > that much. Still, it's worth thinking about. > I think you can get a long way with poll() and curses cbreak mode. You should be able to trade off UI responsiveness and cpu load by adjusting the poll() wait times. > > That way you don't have to force the curses library into a no-wait > > situation when it is not expecting it - > > That's why I used newterm(). (Besides, I can imagine plenty of other > reasons a program might want curses to talk to something other than a > tty, and it seems unreasonable to require all such to set up a pty just > for the purpose.) > Well, let's face it, curses was _designed_ to optimise screen updates to serial terminals. It was the whole premise of the library so it is not surprising that it expects a tty to talk to, it makes termios calls on the expectation that it is talking to a tty. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
