test.test_curses.TestCurses.test_terminfo fails on PPC64LE

[mcepl]

Bug report

Bug description:

On PPC64LE Python 3.15 this test fails with

[ 1826s] ======================================================================
[ 1826s] FAIL: test_terminfo (test.test_curses.TestCurses.test_terminfo)
[ 1826s] ----------------------------------------------------------------------
[ 1826s] Traceback (most recent call last):
[ 1826s]   File "/home/abuild/rpmbuild/BUILD/python315-3.15.0_a1-build/Python-3.15.0a1/Lib/test/test_curses.py", line 688, in test_terminfo
[ 1826s]     self.assertEqual(curses.tigetflag('cols'), -1)
[ 1826s]     ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[ 1826s] AssertionError: 255 != -1

I cannot even understand how could Boolean have value 255. Does PPC64LE different size of long (used by _curses_tigetflag_impl)?

_log.txt

I observe the same error even on the older versions of Python all the way to 3.9 (it apparently is not present in 3.6 at all).

CPython versions tested on:

3.15

Operating systems tested on:

Linux

[sergey-miryanov]

I cannot even understand how could Boolean have value 255.

Unfortunately, tigetflag returns int, not bool. I think we have to add exact checks of what libncurses returns, but I'm not familiar with it.

[serhiy-storchaka]

From the manpage:

   tigetflag, tigetnum, and tigetstr return the value of the capability corresponding to the terminfo cap-code, such as xenl, passed to them.  The cap-code for each capability  is
   given in the table column entitled cap-code code in the capabilities section of terminfo(5).

   These functions return special values to denote errors.

   tigetflag returns

   -1     if cap-code is not a Boolean capability, or

   0      if it is canceled or absent from the terminal description.

cols is not a boolean capability code, it is a numeric capability code (see man:terminfo(5)). tigetflag() should always return -1 for it. I think there is a bug in ncurses on that platform.

What other assertions fail if we skip this?

[Gelbpunkt]

I'm seeing the same issue on powerpc64-unknown-linux-musl (big-endian). I'm in the process of bootstrapping Alpine Linux for this target, and the ppc64le builds Alpine made against ncurses 6.5_p20250816 did not have this problem, while the ones I made against 6.5_p20251115 do. I suspect there may be some regression in between? What's the version of ncurses you were using?

edit: your log says 20251101

[mcepl]

edit: your log says 20251101

That's correct.

[Gelbpunkt]

I do not see test failures anymore since ncurses 20251123.

[mcepl]

Yes, I can confirm, I cannot reproduce with ncurses 20251206 any more.