-though the variables were provided in SVr2.
-.PP
-SVr4 added the \fBvid_attr\fP and \fBvid_puts\fP functions.
-.PP
-There are other low-level functions declared in the \fIcurses\fP header files
-on Unix systems,
-but none were documented.
-The functions marked \*(``obsolete\*('' remained in use
-by the Unix \fBvi\fP(1) editor.
-.SH PORTABILITY
-.SS Extensions
-The functions marked as extensions were designed for \fBncurses\fP(3X),
-and are not found in SVr4 curses, 4.4BSD curses,
-or any other previous version of curses.
-.SS Legacy functions
-X/Open notes that \fBvidattr\fP and \fBvidputs\fP may be macros.
-.PP
-The function \fBsetterm\fP is not described by X/Open and must
-be considered non-portable.
-All other functions are as described by X/Open.
-.SS Legacy data
-\fBsetupterm\fP copies the terminal name to the array \fBttytype\fP.
-This is not part of X/Open Curses, but is assumed by some applications.
-.PP
-Other implementions may not declare the capability name arrays.
-Some provide them without declaring them.
-X/Open does not specify them.
-.PP
-Extended terminal capability names, e.g., as defined by \fB@TIC@\ \-x\fP,
-are not stored in the arrays described here.
-.SS Output buffering
-Older versions of \fBncurses\fP assumed that the file descriptor passed to
-\fBsetupterm\fP from \fBinitscr\fP or \fBnewterm\fP uses buffered I/O,
-and would write to the corresponding stream.
-In addition to the limitation that the terminal was left in block-buffered
-mode on exit (like System V curses),
-it was problematic because \fBncurses\fP
-did not allow a reliable way to cleanup on receiving SIGTSTP.
-.PP
-The current version (ncurses6)
-uses output buffers managed directly by \fBncurses\fP.
-Some of the low-level functions described in this manual page write
-to the standard output.
-They are not signal-safe.
-The high-level functions in \fBncurses\fP use
-alternate versions of these functions
-using the more reliable buffering scheme.
-.SS Function prototypes
-The X/Open Curses prototypes are based on the SVr4 curses header declarations,
-which were defined at the same time the C language was first standardized in
-the late 1980s.
-.bP
-X/Open Curses uses \fBconst\fP less effectively than a later design might,
-in some cases applying it needlessly to values are already constant,
-and in most cases overlooking parameters which normally would use \fBconst\fP.
-Using constant parameters for functions which do not use \fBconst\fP
-may prevent the program from compiling.
-On the other hand, \fIwritable strings\fP are an obsolescent feature.
-.IP
-As an extension, this implementation can be configured to change the
-function prototypes to use the \fBconst\fP keyword.
-The \fIncurses\fP ABI 6 enables this feature by default.
-.bP
-X/Open Curses prototypes \fBtparm\fP with a fixed number of parameters,
-rather than a variable argument list.
-.IP
-This implementation uses a variable argument list, but can be
-configured to use the fixed-parameter list.
-Portable applications should provide 9 parameters after the format;
-zeroes are fine for this purpose.
-.IP
-In response to review comments by Thomas E. Dickey,
-X/Open Curses Issue 7 proposed the \fBtiparm\fP function in mid-2009.
-.IP
-While \fBtiparm\fP is always provided in ncurses,
-the older form is only available as a build-time configuration option.
-If not specially configured, \fBtparm\fP is the same as \fBtiparm\fP.
-.PP
-Both forms of \fBtparm\fP have drawbacks:
-.bP
-Most of the calls to \fBtparm\fP use only one or two parameters.
-Passing nine on each call is awkward.
-.IP
-Using \fBlong\fP for the numeric parameter type is a workaround
-to make the parameter use the same amount of stack as a pointer.
-That approach dates back to the mid-1980s, before C was standardized.
-Since then, there is a standard
-(and pointers are not required to fit in a long).
-.bP
-Providing the right number of parameters for a variadic function
-such as \fBtiparm\fP can be a problem, in particular for string parameters.
-However, only a few terminfo capabilities use string parameters
-(e.g., the ones used for programmable function keys).
-.IP
-The ncurses library checks usage of these capabilities,
-and returns an error if the capability mishandles string parameters.
-But it cannot check if a calling program provides strings in the right
-places for the \fBtparm\fP calls.
-.IP
-The \fB@TPUT@\fR(1) program checks its use of these capabilities with a table,
-so that it calls \fBtparm\fP correctly.
-.SS Special TERM treatment
-If configured to use the terminal-driver,
-e.g., for the MinGW port,
-.bP
-\fBsetupterm\fP interprets a missing/empty TERM variable as the
-special value \*(``unknown\*(''.
-.IP
-SVr4 curses uses the
-special value \*(``dumb\*(''.
-.IP
-The difference between the two is that
-the former uses the \fBgn\fP (\fBgeneric_type\fR) terminfo capability,
-while the latter does not.
-A generic terminal is unsuitable for full-screen applications.
-.bP
-\fBsetupterm\fP allows explicit use of the
-the windows console driver by checking if $TERM is set to
-\*(``#win32con\*('' or an abbreviation of that string.
-.SS Other portability issues
-In System V Release 4, \fBset_curterm\fP has an \fBint\fP return type and
-returns \fBOK\fP or \fBERR\fP. We have chosen to implement the X/Open Curses
-semantics.