+.SS keyname
+.PP
+The \fBkeyname\fP function may return the names of user-defined
+string capabilities which are defined in the terminfo entry via the \fB\-x\fP
+option of \fB@TIC@\fP.
+This implementation automatically 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 \fBuse_extended_names\fP(3X) function controls whether this data is
+loaded when the terminal description is read by the library.
+.SS nofilter/use_tioctl
+.PP
+The \fBnofilter\fP and \fBuse_tioctl\fP routines are specific to \fBncurses\fP.
+They were not supported on Version 7, BSD or System V implementations.
+It is recommended that any code depending on \fBncurses\fP extensions
+be conditioned using NCURSES_VERSION.
+.SS putwin/getwin
+.PP
+The \fBputwin\fP and \fBgetwin\fP functions have several issues with
+portability:
+.bP
+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.
+.IP
+Interestingly enough, according to the copyright dates in Solaris source,
+the functions (along with \fBscr_init\fP, etc.) originated with
+the University of California, Berkeley (in 1982)
+and were later (in 1988) incorporated into SVr4.
+Oddly, there are no such functions in the 4.3BSD curses sources.
+.bP
+Most implementations simply dump the binary \fBWINDOW\fP structure to the file.
+These include SVr4 curses, NetBSD and PDCurses,
+as well as older \fBncurses\fP versions.
+This implementation
+(as well as the X/Open variant of Solaris curses, dated 1995)
+uses textual dumps.
+.IP
+The implementations which use binary dumps use block-I/O
+(the \fBfwrite\fP and \fBfread\fP 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.
+However, reading from a file written using mixed schemes may not be successful.
+.SS unctrl/wunctrl
+.PP
+The XSI Curses standard, Issue 4 describes these functions.
+It states that \fBunctrl\fR and \fBwunctrl\fR will return a null pointer if
+unsuccessful, but does not define any error conditions.
+This implementation checks for three cases:
+.bP
+the parameter is a 7-bit US\-ASCII code.
+This is the case that X/Open Curses documented.
+.bP
+the parameter is in the range 128\-159, i.e., a C1 control code.
+If \fBuse_legacy_coding\fP(3X) has been called with a \fB2\fP parameter,
+\fBunctrl\fP 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.
+.IP
+X/Open Curses does not document whether \fBunctrl\fP can be called before
+initializing curses.
+This implementation permits that,
+and returns the \*(``~@\*('', etc., values in that case.
+.bP
+parameter values outside the 0 to 255 range.
+\fBunctrl\fP returns a null pointer.
+.PP
+The strings returned by \fBunctrl\fR in this implementation are determined
+at compile time,
+showing C1 controls from the upper-128 codes
+with a \*(``~\*('' prefix rather than \*(``^\*(''.
+Other implementations have different conventions.
+For example, they may show both sets of control characters with \*(``^\*('',
+and strip the parameter to 7 bits.
+Or they may ignore C1 controls and treat all of the upper-128 codes as
+printable.
+This implementation uses 8 bits but does not modify the string to reflect
+locale.
+The \fBuse_legacy_coding\fP(3X) function allows the caller to
+change the output of \fBunctrl\fP.
+.PP
+Likewise, the \fBmeta\fP(3X) function allows the caller to change the
+output of \fBkeyname\fP, i.e.,
+it determines whether to use the \*(``M\-\*('' prefix
+for \*(``meta\*('' keys (codes in the range 128 to 255).
+Both \fBuse_legacy_coding\fP(3X) and \fBmeta\fP(3X) succeed only after
+curses is initialized.
+X/Open Curses does not document the treatment of codes 128 to 159.
+When treating them as \*(``meta\*('' keys
+(or if \fBkeyname\fP is called before initializing curses),
+this implementation returns strings \*(``M\-^@\*('', \*(``M\-^A\*('', etc.
+.PP
+X/Open Curses documents \fBunctrl\fP as declared in \fB<unctrl.h>\fP,
+which \fBncurses\fP does.
+However, \fBncurses\fP' \fB<curses.h>\fP includes \fB<unctrl.h>\fP,
+matching the behavior of SVr4 curses.
+Other implementations may not do that.
+.SS use_env/use_tioctl
+.PP
+If \fBncurses\fP is configured to provide the sp-functions extension,
+the state of \fBuse_env\fP and \fBuse_tioctl\fP may be updated before
+creating each \fIscreen\fP rather than once only
+(\fBcurs_sp_funcs\fR(3X)).
+This feature of \fBuse_env\fP
+is not provided by other implementation of curses.