Re: Old curses puzzle

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> It obviously is not the *right* fix, but it's good enough for me for
>> the moment.
> I am reasonably sure that the screen data structures get initialised
> later,

Most of it, no doubt.  But NONL, at least, didn't; if nothing else,
that the program manifested the bug in all cases in the prsence of
MALLOC_OPTIONS=AJVX in the environment demonstrated that to me.

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.

> 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.

> 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.

> 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.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B