According to maximum entropy:
>
>I think it's really really bad that our default xterm termcap entry
>will cause major applications like screen to fail to run.
>

There is a fairly simple fix for this - there is a TERMCAP_BUFSIZE
define in os.h that sets the base size of the termcap entry, it looks
like if you increase that (say, double it) then screen shouldn't
barf.  This is a bit of a hack, screen should really count the amount
of space it needs for the termcap entry and malloc that instead of
malloc'ing a fixed amount.

Our default xterm termcap entry has expanded to support colour and
other such niceties.  The problem we have is that you _just_cannot_
fit all the desirable capabilities into a 1024 byte termcap entry.
Our libterm has, for quite some time now, been able to transparently
handle a >1024 byte termcap entry.  The only real lossage is when a
program decides to manipulate the termcap entry itself - either it
screws it up (ala xterm exporting a truncated TERMCAP) or it gets more
than it expected which is what screen does.  Fortunately, either case
appears to be rather isolated and can be fixed reasonably easily.  If
anyone spots a problem in a package with the extended termcap entry
then _please_ let us know - don't bag us for lifting an arbitrary
limit that makes some things fall over.

BTW I cannot replicate this on my i386 -current system, I believe that
it is happening but not for me.

Whilst we are on this subject, things may get a bit more interesting.
I have a patch that fixes the truncation of TERMCAP for resize and
xterm - they will export the _full_ TERMCAP into the environment.
This may cause some problems with programs that perform an unbounded
copy of TERMCAP into a fixed buffer (they really really should not be
but....)

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, BAE SYSTEMS
===============================================================================