Re: ncurses 6.6-20260314 can no longer read xterm_256color extended attributes on redhat 8+ systems

--7jh7JijwdPU5jpXM
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 16, 2026 at 07:49:17PM +0000, Todd Richmond wrote:
> Thanks for the reply, but I=E2=80=99m not sure on the solution since we h=
ave 1000s of
> VMs that use the base OS 6.1 terminal data files.  6.6-20260301 code with=
 all
> the same configure options and tools works fine, but the 2 week later tar=
ball
> does not so there was a regression during that timeframe.  I have reverte=
d to
> the interim build for now, but since xterm-256color is one of the most
> popular TERM values, this should get noticed once base OS upgrade

I read your original message to state the existing (ncurses 6.1)
no longer works.

That can happen if you installed the database from ncurses 6.6
(using ncurses 6.6), and found that ncurses 6.1 did not accept
terminal entries larger than 4096 bytes.

Actually, checking my centos 8 machine, its (ncurses 6.1) infocmp
accepts the larger file.

	Name        : ncurses
	Version     : 6.1
	Release     : 10.20180224.el8
	Architecture: x86_64
	Install Date: Fri 01 Dec 2023 04:53:19 PM EST

I have a rocky 8 machine - its infocmp also works with current terminfo data
(in both cases, I used current tic to compile the data).

There was a recent bug report in Debian for a case
where an application had too-small buffer size.
(The terminfo changes were a month earlier).

But I changed the maximum size to 32768 in 2017.
=20
> Note that I=E2=80=99m using new code with old data, not the other way aro=
und - i.e.
> -disable-db-install and using base /usr/share/terminfo
>=20
> Redhat 9 has 6.1, but I don=E2=80=99t have a later system to check
>=20
> Todd
>=20
> On 7/16/26, 11:13=E2=80=AFAM, "Thomas Dickey" <[email protected]=
t> wrote:
>=20
> On Thu, Jul 16, 2026 at 04:19:16PM +0000, Todd Richmond wrote:
> > Nurses on Redhat 8 and Alma 9 systems can no longer handle the large ex=
tended
> > attributes of TERM such as xterm_256color
>=20
> Redhat 8 has ncurses 6.1
>=20
> "xterm-256color"
>=20
> (no underscore)
>=20
> > This is proven simply by running =E2=80=9Cinfocmp xterm-256color=E2=80=
=9D vs "infocmp -x
> > xterm-256color=E2=80=9D.  The -x option causes =E2=80=9Cno match in ter=
minal database for
> > terminal type=E2=80=9D.  The =E2=80=9Cclear=E2=80=9D command also retur=
ns =E2=80=9Cunknown terminal type=E2=80=9D
> >
> > Strace on =E2=80=9Cclear=E2=80=9D shows the terminal file opened+read c=
orrectly but it fails
> > during initialization
> >
> > ncurses 6.6-20260301 works correctly so that 2 week window should narro=
w down
> > the problem.  No later version up to and including ncurses 6.6-20260711=
 has a
> > fix

If you're talking about 20260301 to 20260314 (you said 2 week window),
it seems that I changed nothing in that range for _compiling_ terminal
descriptions.  I did this:

20260307
	+ add tic checks for pairs of user-caps strings which are listed in
	  Caps-ncurses.
	+ fix a few gcc warnings.
	+ fix inconsistent checks for expanding special characters with infocmp
	  -L option (report by Stephane Chazelas).
=20
That is, changing some details in "tic -c" and "infocmp -L".

The diffstat for 20260307 is

 NEWS                             |   11 +++++++++--
 VERSION                          |    2 +-
 dist.mk                          |    4 ++--
 ncurses/base/lib_mouse.c         |    5 ++++-
 ncurses/tinfo/comp_parse.c       |    6 ++++--
 ncurses/tinfo/doalloc.c          |    6 +++---
 ncurses/tinfo/read_entry.c       |    9 ++-------
 ncurses/tinfo/read_termcap.c     |    6 +++---
 ncurses/tinfo/write_entry.c      |    7 ++++---
 ncurses/trace/lib_trace.c        |    5 ++---
 ncurses/tty/lib_mvcur.c          |   13 +++++++------
 ncurses/win32con/wcwidth.c       |    6 ++++--
 package/debian-mingw/changelog   |    4 ++--
 package/debian-mingw64/changelog |    4 ++--
 package/debian/changelog         |    4 ++--
 package/mingw-ncurses.nsi        |    4 ++--
 package/mingw-ncurses.spec       |    6 +++---
 package/ncurses.spec             |    6 +++---
 package/ncursest.spec            |    6 +++---
 progs/dump_entry.c               |   12 +++++-------
 progs/infocmp.c                  |    4 ++--
 progs/progs.priv.h               |    4 +++-
 progs/tic.c                      |   18 +++++++++++++++++-
 23 files changed, 89 insertions(+), 63 deletions(-)

Reading that, there's no compile changes (attaching diff, for convenience)

There aren't any code-changes in 20260314.

> sure - the size of the compiled terminal description went past 4096 bytes,
> which is what ncurses 6.1 works with.
>=20
> Mixing old code and new data leads to unexpected results.
>=20
> (compiling a newer terminfo.src with ncurses 6.1 should produce a warning)
>=20
> > Here are my configure options, but I=E2=80=99ve tried many variants w/o=
 diff -
> > especially trying to remove -disable-widec, enable-relocatable,
> > enable-sp-funcs, and with-gpm.  None make a difference.  Ncurses is com=
piled
> > with gcc 15 and 16 and all the absolute latest gnu utils - not the OEM
> > components

I'm only using the "OEM" (gcc 8) on centos/rocky, and using the configure
and compiler options in the spec file under the package directory in the
sources.

> > --disable-db-install --disable-widec --enable-fvisibility --enable-relo=
catable --enable-pc-files --enable-sp-funcs --libdir=3D$dstlibdir --with-cx=
x-shared --with-gpm --with-shared --datadir=3D/usr/share

If you disable widec, you'll lose the extended numbers, and _that_ won't
load terminal data using the extended numbers.  Your message didn't list
the options actually used; the comment above seems to be about alternatives
tried.

> >
> > TIA
> >
>=20
> --
> Thomas E. Dickey <[email protected]<mailto:dickey@invisible-isl=
and.net>>
> https://invisible-island.net
>=20

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

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

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

iQGzBAABCgAdFiEEGYgtkt2kxADCLA1WzCr0RyFnvgMFAmpZSfgACgkQzCr0RyFn
vgPGLgwAsGv/GEGBnYF28ovPMYjJDMJpoV9NMm6iH/pkdMgKJOmymzHawNe/UWYT
GgAbzINO53cKrD2EaxIWfsIOo/myPU3GgBJDwai7X9cinESRH1B/fvGeOnVlQpG7
TK7rYVYfCJt54iG/tsSbVBmQnamOPGRZfplnY5sv94k+EIVsSOMlViIsfnL9rjF5
/FmA4S16xY5zIUNq7T20zT4gzwfLmBHYWbNmM40Pb1MVn7XlmOsZR9LtpOj7PRCs
zFwl8YFKDoiGcWtu/lpaCR/BGtIcFvYO9rDxxb3Bfk5wgU1IAKC3SeULS5W8lilK
OmOIV0lhm/RhZRzpPjUkz3zcI7+nzwBXWRmEL+eSDoZCDQ7j0gdwMjwsyKAvuPJ2
Vm5hXyzl0lSHXxzc0H71t+thLVV0fvzJLtbinQcywT/YZUrty57cG6n9agaImqgj
W4sE4nNiN3OwRRMS38sM2Fm4U2dfit6L0bm26gn/2gGW0uqgk0bqFwg9+NdnU3Mk
QWd0c85X
=r1au
-----END PGP SIGNATURE-----

--7jh7JijwdPU5jpXM--