Subject: lib/2792: Patch for conformance with psd/19.curses
To: None <>
From: Peter Seebach <>
List: netbsd-bugs
Date: 09/29/1996 11:34:05
>Number:         2792
>Category:       lib
>Synopsis:       werase() and friends don't move to 0, 0.
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    lib-bug-people (Library Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Sep 29 09:50:01 1996
>Originator:     Peter Seebach
Usenet Fact Police
>Release:        1.2
System: NetBSD taniemarie 1.2_BETA NetBSD 1.2_BETA (SEEBS) #0: Fri Aug 16 17:16:09 CDT 1996 seebs@taniemarie:/usr/src/sys/arch/amiga/compile/SEEBS amiga

	werase(), erase(), wclear(), and clear() are all supposed to move
	to 0, 0 in the window erased or cleared.  They don't.

	I believe I submitted this, and it got bounced for lack of
	documentation that this is supposed to happen.  So...


               Resets  the  entire  window  to  blanks.   If  win is a
               screen, this sets the clear flag, which  will  cause  a
               clear-screen  sequence to be sent on the next refresh()
               call.  This also moves the current (y, x)  co-ordinates
               to (0, 0).


               Erases  the  window to blanks without setting the clear
               flag.  This is analagous to  clear(),  except  that  it
               never causes a clear-screen sequence to be generated on
               a refresh().  This has no associated "mv" command.

	I read this as asserting that erase also moves to 0, 0, because
	it is supposed to behave like clear.

	This behavior has been observed on other systems, and comes up
	because some programs assume the observed behavior, or the documented

	UTSL, or write simple programs that clear a window and put a character
	in it.
***	Sun Sep 29 11:29:48 1996
--- erase.c	Sun Sep 29 11:29:58 1996
*** 68,72 ****
--- 68,73 ----
  			__touchline(win, y, minx, maxx - win->lines[y]->line,
+ 	wmove(win, 0, 0);
  	return (OK);