Skip to content

Exact reporting of curses C function failures #133579

Closed

Description

@picnixz

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?

cc @encukou


Note

We will not backport these fixes as they could break existing code that could be surprised by a new exception.

Linked PRs

Activity

  1. self-assigned this
    on May 7, 2025
  2. encukou commented on May 17, 2025

    @encukou
    Member

    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.

  3. added
    type-bugAn unexpected behavior, bug, or error
    triagedThe issue has been accepted as valid by a triager.
    and removed
    type-featureA feature request or enhancement
    triagedThe issue has been accepted as valid by a triager.
    on May 18, 2025
  4. picnixz commented on May 18, 2025

    @picnixz
    MemberAuthor

    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.

  5. picnixz commented on May 19, 2025

    @picnixz
    MemberAuthor

    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.

  6. added a commit that references this issue on May 27, 2025
  7. added a commit that references this issue on Jun 8, 2025
  8. added a commit that references this issue on Jun 19, 2025
  9. added 2 commits that reference this issue on Jul 12, 2025
  10. added 2 commits that reference this issue on Aug 4, 2025
  11. added a commit that references this issue on Aug 19, 2025
  12. added a commit that references this issue on Jun 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

extension-modulesC modules in the Modules dirtype-bugAn unexpected behavior, bug, or error

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions