Re: File descriptors are int, not short

--GPBegeT2EwXcZE7b
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 29, 2026 at 09:59:08PM +0000, Antonio Ni=F1o D=EDaz wrote:
> Hi,
>=20
> 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?

probably safe.  But applications could pass in "any" file descriptor,
and just because it's been done this way a long time doesn't stop someone
=66rom making file descriptors over a large range (think of process ids...)

casts are useful where the types can't be matched, so I made the change to
remove casts
=20
> Antonio
>=20
> On Monday, 22 June 2026 at 09:03, Thomas Dickey <dickey@invisible-island.=
net> wrote:
>=20
> > On Mon, Jun 22, 2026 at 12:31:06AM +0000, Antonio Ni=F1o D=EDaz wrote:
> > > Hello,
> > >=20
> > > I've noticed that a few lines of the library are treating file descri=
ptors as short instead of int. I've downloaded the 6.6 tarball, and the aff=
ected 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 TERMI=
NAL
> > opaque (to allow for 32-bit integer values for capabilities).  I was ab=
le
> > 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
> >
>=20

--=20
Thomas E. Dickey <[email protected]>
https://invisible-island.net

--GPBegeT2EwXcZE7b
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGzBAABCgAdFiEEGYgtkt2kxADCLA1WzCr0RyFnvgMFAmpC87AACgkQzCr0RyFn
vgNK5Av/Uu0okCppfjt6yxutmMxdBqyNyph7oQDYZZrDGjqck1bKbsgb2NhIM6NV
3xiIximMOSndAOD8hphi/M259PGMzcgeuoWj4OgNxNH/cf83HLBDeMcRLUOdKcnp
MKf6btmyc7zFtcww4XmFh+vUxD3GnkLB83QldGwNuxsub+KWaxalTZ42lNKHQvAK
qf9REYmiAmHye0SPuAfULmEN9WytGqH59gBRmrsrEhJfJjIO5g3xOK1f+WOTENC7
01VVwgxjaHDd8mRv1ft3NIR3BRol/s2D3qQxH+zo+u+K63gHGERbDfVfvLyP7sDI
orDtC4/rNEnpqHi3PpveEOOooq6dhHA0leu/H0H2No5N0JjJgj7qJL+UnLLZGC9k
kr5zIJgWlV/rKyfGcgomvNDlhwSImYn1P6rgChJLfoutacVdQmdaBKx2LZF1Y1uh
RMb16B2FlnLgAnZHhfafZi+9+lDxy1PMy6VanccpUKp+iHeOKWk3Petb9JQlGe0u
Pbz4E4VJ
=lUqS
-----END PGP SIGNATURE-----

--GPBegeT2EwXcZE7b--