Re: File descriptors are int, not short

Hi,

Thanks for the context about this issue. How could this affect a program ne=
gatively? In my system, file descriptors use up to 31 bits of the int (stdi=
n, stdout and stderr are 0, 1 and 2 respectively so that's ok). I'm not ope=
ning the console from a file. I guess I'm safe?

Antonio

On Monday, 22 June 2026 at 09:03, Thomas Dickey <[email protected]=
t> wrote:

> On Mon, Jun 22, 2026 at 12:31:06AM +0000, Antonio Ni=C3=B1o D=C3=ADaz wro=
te:
> > Hello,
> >=20
> > I've noticed that a few lines of the library are treating file descript=
ors as short instead of int. I've downloaded the 6.6 tarball, and the affec=
ted lines are:
> >=20
> > ncurses/term.priv.h:143
> > ncurses/tinfo/lib_setup.c:957ncurses/tinfo/lib_setup.c:1007
> >=20
> > You can find them with "grep -rn Filedes | grep short"
> >=20
> > 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.
>=20
> I see (thanks).  That was leftover from 1995, declared in term.h (which
> meant that changing the type would be a binary compatibility issue).
>=20
> In 2010, I added the casts per gcc warnings.
>=20
> In 2021 I moved the definition into term.priv.h as part of making TERMINA=
L
> 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.
>=20
> So it wasn't (my) error, but rather a missed opportunity to make a fix
> without side-effects.
>=20
> --=20
> Thomas E. Dickey <[email protected]>
> https://invisible-island.net
>