Scott, thanks a lot!

Victor, can you test this patch?

Finally had a chance to take a look at this one... found the source of the problem:

termcap.c:156
        case T_STR:
          D_tcs[i].str = e_tgetstr(term[i].tcname, &tp);

tgetstr(), the tp buffer is expected to have 1024, but tp is advanced on return... and there's no check on overflow when called repeatedly.  If the source is termcap, a 1024 buffer is fine as that's the standard termcap size limit anyway... with a terminfo source, the limit is really T_STR(1024) * T_N entries... unlikely, but quite legal.

There's a function called t_agetstr which handles (re)allocation of the buffer, but may not be available on all platforms.

A portable solution would be to pass NULL as tp and then copy the return value to a realloc'd buffer locally sized to handle the value.

Using TERMCAP_BUFSIZE for tp is really not correct here (regardless of value).  I could supply a patch to handle a realloc buffer solution, unless someone has a better solution?

In version 4.8.0 screen can corrupt memory when reading terminfo/termcap files.

I use st terminal with environment variable TERM=st-256color. If I have compiled st.info (with warnings) from the source with

tic -o "$HOME/.terminfo" st.info

trying to start screen results in one process becoming a zombie and another process blocking terminal until I press Ctrl+\.

If I have compiled st.info as recommended in st FAQ with

tic -o "$HOME/.terminfo" -x st.info

trying to reattach to screen session results in an infinite loop in _nc_find_type_entry in libncursesw.so.6 (bug #58132)

The problem is not present in version 4.7.0.
Workaround: add " -DTERMCAP_BUFSIZE=2048" to CPPFLAGS environment variable and reconfigure/rebuild. In that case problem is no longer present.

P.S. bugtracker misses 4.8.0 entry in the release field.