On Sat, Dec 16, 2023 at 10:48:33AM +0100, Sven Joachim wrote: > On 2023-12-11 15:12 -0500, Thomas Dickey wrote: > > > On Mon, Dec 11, 2023 at 05:47:23PM +0100, Sven Joachim wrote: > >> > >> I am not familiar with Mercurial, but most likely this has been > >> triggered by the following change in the 2023111 patchlevel: > >> > >> ,---- > >> | 20231111 > >> | + modify endwin() to return an error if it is called again without an > >> | intervening screen update (report by Rajeev Pillai, NetBSD #57592). > >> `---- > >> > >> NetBSD #57592 is > >> https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57592 . > > > > sounds plausible. fwiw, handling error returns (other than throwing an > > exception) is something that developers should do. > > I may be something that developers should do, but in the case of > endwin() hardly anybody does it. In C/C++ programs, nobody seems to > check the return value of endwin() in the first place, so this change is > not really going to make a difference. > > In Python the situation is different, because a curses.error exception > occurs. The wrapper does not handle it, FWIW. > > > I suspect that making ncurses not return error-codes is a step in the wrong > > direction. The example in the NetBSD bug report was clearly a defect in > > the application using ncurses. > > The question is how many such defects are there, and how do we find > them? Based on the current report I looked on codesearch.debian.net for > more instances where programs make the same mistake as mercurial (using > both curses.wrapper and calling curses.endwin() explicitly). I could
which does this:
finally:
# Set everything back to normal
if 'stdscr' in locals():
stdscr.keypad(0)
curses.echo()
curses.nocbreak()
curses.endwin()
(and appears to have its own problems with copy/paste: the settings changes
are redundant).
> not find something as broken as the current case, but there seem to be a
> few instances where programs call curses.endwin() in a signal handler,
> and that may cause issues like #1058626 in pulsemixer.
>
> > In this case, I chose to make it behave like SVr4 curses. Explaining this
> > nicely in a portability section of the manpage is still on my to-do list,
> > but it's clear in the note that I made. NetBSD curses returns no error,
> > but it's based on some code to handle SIGTSTP.
>
> I think it is too late to change behavior in ncurses. This change is
> going to cause problems for end users which outweigh any benefits from
> forcing changes in non-conforming applications, IMHO.
If I weren't spending about a quarter of my time repairing configure scripts
broken by "improvements" to compiler warnings, I'd be more agreeable.
--
Thomas E. Dickey <dic...@invisible-island.net>
https://invisible-island.net
signature.asc
Description: PGP signature
