Re: Old curses puzzle

[Brett Lymn <blymn%internode.on.net@localhost>]

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"