+.PP
+Calling \fBendwin\fP does not dispose of the memory allocated in \fBinitscr\fP
+or \fBnewterm\fP.
+Deleting a \fBSCREEN\fP provides a way to do this:
+.bP
+X/Open Curses does not say what happens to \fBWINDOW\fPs when \fBdelscreen\fP
+\*(``frees storage associated with the \fBSCREEN\fP\*(''
+nor does the SVr4 documentation help,
+adding that it should be called after \fBendwin\fP if a \fBSCREEN\fP
+is no longer needed.
+.bP
+However, \fBWINDOW\fPs are implicitly associated with a \fBSCREEN\fP.
+so that it is reasonable to expect \fBdelscreen\fP to deal with these.
+.bP
+SVr4 curses deletes the standard \fBWINDOW\fP structures
+\fBstdscr\fP and \fBcurscr\fP as well as a work area \fBnewscr\fP.
+SVr4 curses ignores other windows.
+.bP
+Since version 4.0 (1996), ncurses has maintained a list of all windows
+for each screen,
+using that information to delete those windows when \fBdelscreen\fP is called.
+.bP
+NetBSD copied this feature of ncurses in 2001.
+PDCurses follows the SVr4 model,
+deleting only the standard \fBWINDOW\fP structures.
+.SS Unset TERM Variable
+.PP
+If the TERM variable is missing or empty, \fBinitscr\fP uses the
+value \*(``unknown\*('',
+which normally corresponds to a terminal entry with the \fIgeneric\fP
+(\fIgn\fP) capability.
+Generic entries are detected by \fBsetupterm\fP
+(see curs_terminfo(3X)) and cannot be used for full-screen operation.
+Other implementations may handle a missing/empty TERM variable differently.
+.SS Signal Handlers
+.PP
+Quoting from X/Open Curses, section 3.1.1:
+.RS 5
+.hy 0
+.PP
+.I Curses implementations may provide for special handling of the
+.I \fBSIGINT\fP,
+.I \fBSIGQUIT\fP and
+.I \fBSIGTSTP\fP signals
+.I if their disposition is \fBSIG_DFL\fP at the time
+\fBinitscr\fI is called \fR...
+.PP
+.I Any special handling for these signals may remain in effect for the
+.I life of the process or until the process changes the disposition of
+.I the signal.
+.PP
+.I None of the Curses functions are required to be safe
+.I with respect to signals \fP...
+.RE
+.hy
+.PP
+This implementation establishes signal handlers during initialization,
+e.g., \fBinitscr\fP or \fBnewterm\fP.
+Applications which must handle these signals should set up the corresponding
+handlers \fIafter\fP initializing the library:
+.TP 5
+.B SIGINT
+The handler \fIattempts\fP to cleanup the screen on exit.
+Although it \fIusually\fP works as expected, there are limitations:
+.RS 5
+.bP
+Walking the \fBSCREEN\fP list is unsafe, since all list management
+is done without any signal blocking.
+.bP
+On systems which have \fBREENTRANT\fP turned on, \fBset_term\fP uses
+functions which could deadlock or misbehave in other ways.
+.bP
+\fBendwin\fP calls other functions, many of which use stdio or
+other library functions which are clearly unsafe.
+.RE
+.TP 5
+.B SIGTERM
+This uses the same handler as \fBSIGINT\fP, with the same limitations.
+It is not mentioned in X/Open Curses, but is more suitable for this
+purpose than \fBSIGQUIT\fP (which is used in debugging).
+.TP 5
+.B SIGTSTP
+This handles the \fIstop\fP signal, used in job control.
+When resuming the process, this implementation discards pending
+input with \fBflushinput\fP (see curs_util(3X)), and repaints the screen
+assuming that it has been completely altered.
+It also updates the saved terminal modes with \fBdef_shell_mode\fP
+(see \fBcurs_kernel\fP(3X)).
+.TP 5
+.B SIGWINCH
+This handles the window-size changes which were ignored in
+the standardization efforts.
+The handler sets a (signal-safe) variable
+which is later tested in \fBwgetch\fP (see curs_getch(3X)).
+If \fBkeypad\fP has been enabled for the corresponding window,
+\fBwgetch\fP returns the key symbol \fBKEY_RESIZE\fP.
+At the same time, \fBwgetch\fP calls \fBresizeterm\fP to adjust the
+standard screen \fBstdscr\fP,
+and update other data such as \fBLINES\fP and \fBCOLS\fP.