>> 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 [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
