Subject: lib/25397: probable glitch in curses
To: None <gnats-bugs@gnats.NetBSD.org>
From: None <dholland@eecs.harvard.edu>
List: netbsd-bugs
Date: 04/29/2004 18:24:18
>Number:         25397
>Category:       lib
>Synopsis:       probable glitch in curses
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 29 22:25:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     David A. Holland <dholland@eecs.harvard.edu>
>Release:        NetBSD 1.6ZG (20031215) [but see below]
>Organization:
   Harvard EECS
>Environment:
System: NetBSD alicante 1.6ZG NetBSD 1.6ZG (ALICANTE) #8: Wed Mar 17 18:47:39 EST 2004 dholland@alicante:/usr/src/sys/arch/i386/compile/ALICANTE i386
Architecture: i386
Machine: i386
>Description:
	While porting curses, I built it with -Wuninitialized and
	spotted the following likely bug:

	In resize.c, in the function resizeterm(), there are two loops
	through a list of windows. The first assigns the scratch variable
	"win" to the actual window structure as a shorthand/convenience.
	The second loop also uses "win", but doesn't assign it. This 
	prompts gcc to warn that "win" might be used uninitialized,
	because gcc doesn't know if the list might be empty (which
	would result in the first loop executing zero times).

	Judging by what the function does, I strongly suspect that the
	second loop is not supposed to reference the window structure
	of the last window in the list the way it actually does, but
	instead to treat all the windows on the list uniformly.

	However, I'm not absolutely sure, and I haven't tried it (nor
	can I think offhand of anything whose behavior would be
	affected...) so someone who knows curses should examine it.

	Note that I was working on version 1.9 of resize.c; version
	1.10 has been committed that suppresses the gcc warning.
	However, this came with an "XXX" comment, so I'm guessing that
	the issue wasn't examined in detail at that point. :-)

	If I'm wrong, which is entirely possible, a comment explaining
	what's going on might be helpful.

>How-To-Repeat:
	n/a
>Fix:

	Possible, untested, patch:

Index: resize.c
===================================================================
RCS file: /cvsroot/src/lib/libcurses/resize.c,v
retrieving revision 1.10
diff -U3 -r1.10 resize.c
--- resize.c	16 Mar 2004 07:49:01 -0000	1.10
+++ resize.c	29 Apr 2004 22:22:03 -0000
@@ -104,7 +104,7 @@
 int
 resizeterm(int nlines, int ncols)
 {
-	WINDOW *win = NULL;	/* XXX gcc -Wuninitialized */
+	WINDOW *win;
 	struct __winlist *list;
 	int newlines, newcols;
 
@@ -143,7 +143,7 @@
 
 	  /* tweak the flags now that we have updated the LINES and COLS */
 	for (list = _cursesi_screen->winlistp; list != NULL; list = list->nextp) {
-		if (!(win->flags & __ISPAD))
+		if (!(list->winp->flags & __ISPAD))
 			__swflags(list->winp);
 	}
 
>Release-Note:
>Audit-Trail:
>Unformatted: