+
+</PRE><H3><a name="h3-keyname">keyname</a></H3><PRE>
+ The <STRONG>keyname</STRONG> function may return the names of user-defined
+ string capabilities which are defined in the terminfo en-
+ try via the <STRONG>-x</STRONG> option of <STRONG>tic</STRONG>. This implementation auto-
+ matically assigns at run-time keycodes to user-defined
+ strings which begin with "k". The keycodes start at
+ KEY_MAX, but are not guaranteed to be the same value for
+ different runs because user-defined codes are merged from
+ all terminal descriptions which have been loaded. The
+ <STRONG><A HREF="curs_extend.3x.html">use_extended_names(3x)</A></STRONG> function controls whether this data
+ is loaded when the terminal description is read by the li-
+ brary.
+
+
+</PRE><H3><a name="h3-nofilter_use_tioctl">nofilter/use_tioctl</a></H3><PRE>
+ The <STRONG>nofilter</STRONG> and <STRONG>use_tioctl</STRONG> routines are specific to
+ <STRONG>ncurses</STRONG>. They were not supported on Version 7, BSD or
+ System V implementations. It is recommended that any code
+ depending on <STRONG>ncurses</STRONG> extensions be conditioned using
+ NCURSES_VERSION.
+
+
+</PRE><H3><a name="h3-putwin_getwin">putwin/getwin</a></H3><PRE>
+ The <STRONG>putwin</STRONG> and <STRONG>getwin</STRONG> functions have several issues with
+ portability:
+
+ <STRONG>o</STRONG> The files written and read by these functions use an
+ implementation-specific format. Although the format
+ is an obvious target for standardization, it has been
+ overlooked.
+
+ Interestingly enough, according to the copyright dates
+ in Solaris source, the functions (along with <STRONG>scr_init</STRONG>,
+ etc.) originated with the University of California,
+ Berkeley (in 1982) and were later (in 1988) incorpo-
+ rated into SVr4. Oddly, there are no such functions
+ in the 4.3BSD curses sources.
+
+ <STRONG>o</STRONG> Most implementations simply dump the binary <STRONG>WINDOW</STRONG>
+ structure to the file. These include SVr4 curses,
+ NetBSD and PDCurses, as well as older <STRONG>ncurses</STRONG> ver-
+ sions. This implementation (as well as the X/Open
+ variant of Solaris curses, dated 1995) uses textual
+ dumps.
+
+ The implementations which use binary dumps use block-
+ I/O (the <STRONG>fwrite</STRONG> and <STRONG>fread</STRONG> functions). Those that use
+ textual dumps use buffered-I/O. A few applications
+ may happen to write extra data in the file using these
+ functions. Doing that can run into problems mixing
+ block- and buffered-I/O. This implementation reduces
+ the problem on writes by flushing the output. Howev-
+ er, reading from a file written using mixed schemes
+ may not be successful.
+
+
+</PRE><H3><a name="h3-unctrl_wunctrl">unctrl/wunctrl</a></H3><PRE>
+ The XSI Curses standard, Issue 4 describes these func-
+ tions. It states that <STRONG>unctrl</STRONG> and <STRONG>wunctrl</STRONG> will return a
+ null pointer if unsuccessful, but does not define any er-
+ ror conditions. This implementation checks for three cas-
+ es:
+
+ <STRONG>o</STRONG> the parameter is a 7-bit US-ASCII code. This is the
+ case that X/Open Curses documented.
+
+ <STRONG>o</STRONG> the parameter is in the range 128-159, i.e., a C1 con-
+ trol code. If <STRONG>use_legacy_coding</STRONG> has been called with
+ a <STRONG>2</STRONG> parameter, <STRONG>unctrl</STRONG> returns the parameter, i.e., a
+ one-character string with the parameter as the first
+ character. Otherwise, it returns "~@", "~A", etc.,
+ analogous to "^@", "^A", C0 controls.
+
+ X/Open Curses does not document whether <STRONG>unctrl</STRONG> can be
+ called before initializing curses. This implementa-
+ tion permits that, and returns the "~@", etc., values
+ in that case.
+
+ <STRONG>o</STRONG> parameter values outside the 0 to 255 range. <STRONG>unctrl</STRONG>
+ returns a null pointer.
+