?
To: None <lm@cs.rmit.edu.au>
From: J.T. Conklin <jtc@NetBSD.ORG>
List: tech-userlevel
Date: 10/14/1997 16:47:17
> greetings,
> whilst i was WARNSifying various parts of the tree, I noticed
> that the termcap(3) functions (-ltermcap) are defined in <curses.h>
> (even though the manual page doesn't document this)
I think the manual should be updated to document the termcap
functions.
> this is suboptimal because there are lots of other definitions in
> <curses.h> which aren't related to the termcap(3) functions which
> cause conflicts with non-curses using programs.
Curses is one of the worst examples of a library polluting the
namespace. It has half a zillion functions and variables, some which
are not documented or intended to be used by applications, which make
adding curses support to existing applications ... interesting ... to
say the least. And since every vendor provides a slightly different
curses.h, fixing a program once doesn't mean you're done.
> mrg and i discussed this, and feel that we should do the following:
> * create <termcap.h> with the stuff from termcap(3)
> * change <curses.h> to include <termcap.h> instead of
> defining the termcap(3) stuff
> * modify the programs in the tree that currently just use
> the termcap(3) stuff (and not the <curses.h> stuff),
> and probably privately define the stuff in termcap(3),
> to include <termcap.h> instead...
I dislike this solution for the following reasons:
* adds new non-standard header <termcap.h>. It is unlikely
that this is going to be adopted by other vendors. If
we modify our programs to use the new header, it makes it
more difficult to port those programs to other systems.
* With XPG4's curses standard, curses implementations are
becoming reasonably compatible. A standard curses.h makes
it reasonable to include the header to get the definitions
of the t* functions. We'll have such an implementation soon,
as soon as the ncurses handover is complete.
> objections? otherwise i'll do this in the next day or so.
--jtc