Hi, Thanks for the context about this issue. How could this affect a program negatively? In my system, file descriptors use up to 31 bits of the int (stdin, stdout and stderr are 0, 1 and 2 respectively so that's ok). I'm not opening the console from a file. I guess I'm safe?
Antonio On Monday, 22 June 2026 at 09:03, Thomas Dickey <[email protected]> wrote: > On Mon, Jun 22, 2026 at 12:31:06AM +0000, Antonio Niño Díaz wrote: > > Hello, > > > > I've noticed that a few lines of the library are treating file descriptors > > as short instead of int. I've downloaded the 6.6 tarball, and the affected > > lines are: > > > > ncurses/term.priv.h:143 > > ncurses/tinfo/lib_setup.c:957ncurses/tinfo/lib_setup.c:1007 > > > > You can find them with "grep -rn Filedes | grep short" > > > > The fix would involve changing the type of the variable in term.priv.h to > > int, and removing the two casts to short in lib_setup.c. > > I see (thanks). That was leftover from 1995, declared in term.h (which > meant that changing the type would be a binary compatibility issue). > > In 2010, I added the casts per gcc warnings. > > In 2021 I moved the definition into term.priv.h as part of making TERMINAL > opaque (to allow for 32-bit integer values for capabilities). I was able > to make it opaque because only the first member of TERMINAL was used in > calling applications. > > So it wasn't (my) error, but rather a missed opportunity to make a fix > without side-effects. > > -- > Thomas E. Dickey <[email protected]> > https://invisible-island.net >
