You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Exact reporting of curses C function failures #133579
When calling some curses C functions, we ignore their return values. Those are:
in PyCursesWindow_dealloc, we ignore delwin() errors
in _curses_initscr_impl, we ignore wrefresh() errors
in _curses_window_addstr_impl, we ignore wattrset() errors and prefer reporting errors due to adding strings. Same for the insstr* functions
in _curses_window_box_impl, we ignore the error returned by box(). This is correct because the manual says (for box):
All routines return the integer OK. The SVr4.0 manual says "or a non-negative integer if immedok is set", but this appears to be an error. X/Open does not define any error conditions. This implementation returns an error if the window pointer is null.
In this case, I think it's better to explicitly suppress the return value and link the manpage.
The question now is:
What should we do for a failing delwin() in the destructor?
What should we do for wattrset() when this routine is not the "important" one?
What should we do for a failing delwin() in the destructor?
Set an exception and call PyErr_WriteUnraisable, so that it's caught by unraisablehook.
What should we do for wattrset() when this routine is not the "important" one?
In _curses_window_addstr_impl, wattrset is only called if the user explicitly called addstr with an attr argument. Failure to set them should be a hard error, to be handled by the user.
_curses_window_box_impl
IMO, if an error is reported, something is wrong and we should raise an exception.
IMO, these would be bugfixes, but should not be backported.
Thanks. I've found other occurrences where curses C functions are called but the error handling is not done. It's just that it was sometimes under ifdef that I missed. I need #125844 to be merged first so that I can use the helpers out there so I'm holding this work for now.
On failure, _curses.window.getstr also return an empty string instead of reporting the error. It may be fine, but I don't know if it wouldn't be better to actually report the possible error.
Activity
encukou commentedon May 17, 2025
Set an exception and call
PyErr_WriteUnraisable, so that it's caught byunraisablehook.In
_curses_window_addstr_impl,wattrsetis only called if the user explicitly calledaddstrwith an attr argument. Failure to set them should be a hard error, to be handled by the user.IMO, if an error is reported, something is wrong and we should raise an exception.
IMO, these would be bugfixes, but should not be backported.
picnixz commentedon May 18, 2025
Thanks. I've found other occurrences where curses C functions are called but the error handling is not done. It's just that it was sometimes under ifdef that I missed. I need #125844 to be merged first so that I can use the helpers out there so I'm holding this work for now.
picnixz commentedon May 19, 2025
On failure,
_curses.window.getstralso return an empty string instead of reporting the error. It may be fine, but I don't know if it wouldn't be better to actually report the possible error.gh-133579: consistently report C curses function failures (#134327)
gh-133579: correctly report C curses errors in `_curses_panel` (#134629)
pythongh-133579: correctly report C curses errors in `_curses_panel` (p…
pythongh-133579: consistently report C curses function failures (pyth…
pythongh-133579: correctly report C curses errors in `_curses_panel` (p…
pythongh-133579: consistently report C curses function failures (pyth…
pythongh-133579: correctly report C curses errors in `_curses_panel` (p…
pythongh-133579: correctly report C curses errors in `_curses_panel` (p…
pythongh-133579: consistently report C curses function failures (pyth…