bug fix for zsh 3.0.0

bug fix for zsh 3.0.0

[Keith Bostic]

Some termcap databases (e.g., the one distributed with ncurses) have
entries larger than 1K.  When combined with termcap library code that
doesn't limit the length of the copied record to 1K (e.g., old 4BSD
implementations) it can drop core.

--keith

Index: init.c
===================================================================
RCS file: /master/contrib/zsh-3.0.0/Src/init.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -c -r1.1.1.1 -r1.2
*** init.c	1996/10/02 17:10:14	1.1.1.1
--- init.c	1996/10/25 13:31:56	1.2
***************
*** 405,411 ****
  	errflag = 0;
  	return termok = TERM_BAD;
      } else {
! 	char tbuf[1024], *pp;
  	int t0;
  
  	termok = TERM_OK;
--- 405,411 ----
  	errflag = 0;
  	return termok = TERM_BAD;
      } else {
! 	char tbuf[4096], *pp;
  	int t0;
  
  	termok = TERM_OK;

Re: bug fix for zsh 3.0.0

[Zoltan Hidvegi]

Keith Bostic wrote:
> Some termcap databases (e.g., the one distributed with ncurses) have
> entries larger than 1K.  When combined with termcap library code that
> doesn't limit the length of the copied record to 1K (e.g., old 4BSD
> implementations) it can drop core.

That can only happen if a single capability string is bigger thatn 1024
bytes.  Did you really see a coredump from that part of the code or you
just see it as a theoretical bug?

It is true that if the termcap database is longer that 2048 bytes and
tgetent does not accept NULL to automatically allocate buffer.

Zoltan

Re: bug fix for zsh 3.0.0

[Keith Bostic]

> Show me an example.  A tercap string usually tells you things like how to
> move the cursor to a given screen position.  This is never that big.  What
> termcap feature has such a long string?

You're absolutely right, I misred the zsh code.  You've upgraded
the size of the termbuf array to 2K since the last version, which
is almost certainly large enough.

Thanks, and I apologize for the mistake!
--keith

Re: bug fix for zsh 3.0.0

[Zoltan Hidvegi]

Keith Bostic wrote:
> Single capability strings in some termcap databases are bigger
> than 1K.

Show me an example.  A tercap string usually tells you things like how to
move the cursor to a given screen position.  This is never that big.  What
termcap feature has such a long string?

> I really saw a coredump in a previous version of zsh.
> The fix for that version was:
[...]
> 	-EXTERN char termbuf[1024];
> 	+EXTERN char termbuf[4096];

That's a completely different bug.  It caused problem when the _whole_
termcap database was long.  Your patch fixes a case where a single entry in
the database is more than 1024 bytes.  I still do not believe that such
termcap entries exist.  Note that zsh use only a given subset of the termcap
entries listed in globals.h in the tccapnams global array.  One of these
must be longer than 1024 bytes to get a coredump.  If one of these entries
is that long on your system it is probably better to disable it because
that is probably not the most optimal way to achieve that functionality.

Zoltan

Re: bug fix for zsh 3.0.0

[Keith Bostic]

> Keith Bostic wrote:
>> Some termcap databases (e.g., the one distributed with ncurses) have
>> entries larger than 1K.  When combined with termcap library code that
>> doesn't limit the length of the copied record to 1K (e.g., old 4BSD
>> implementations) it can drop core.
>
> That can only happen if a single capability string is bigger thatn 1024
> bytes.  Did you really see a coredump from that part of the code or you
> just see it as a theoretical bug?

Single capability strings in some termcap databases are bigger
than 1K.  I really saw a coredump in a previous version of zsh.
The fix for that version was:

	--- ./src/zsh.h 1995/12/07 21:40:24     1.1
	+++ ./src/zsh.h 1996/10/23 16:18:58
	@@ -1855,7 +1855,7 @@
 
	 /* the termcap buffer */
 
	-EXTERN char termbuf[1024];
	+EXTERN char termbuf[4096];
 
	 /* $TERM */

--keith