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
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.
Cheers,
Sven
