Re: lib_getch.c

[Thomas Dickey]

On Sun, Aug 04, 2002 at 06:35:04AM +0200, Philippe Blain wrote:
> ----
> Files : ncurses/base/lib_getch.c
>         ncurses/base/lib_getstr.c
> 
> MAJOR PROBLEM :
> I would like to point out some INCOHERENCES.
> I don't have a C flow program for tracing functions calls, but it seems to
> me
> that in the treatement of input characters, a loop has taken place between
> some functions after modifications and modifications (since 1.9.9g at
> least).
>     I refer to wgetch().
> If you look at functions calls in these files, you can see that, starting
> from wgetch(), dependencies are like this schema :
> 
>     --->  wgetch()  ---->  _nc_wgetch()  ---->  wgetnstr()  -----
>     |                                                           |
>     ------------------------["calls"]----------------------------
> 
> Q: Which function was the first defined ??????

You can treat wgetch/_nc_wgetch as the "same".  I split that pair to make it
convenient to implement wget_wch(), which needs a different convention for
return-value.  (I have a different patch in my backlog for the same area,
so I may revisit the tradeoff between ifdef-ugliness versus the small increase
in size introduced by that split).

more to the point - based on the comment above the wgetnstr() call I can see
immediately that it preceded 1.9.9g - in fact, I see it first in the 3 April
1996 version of that file, which you may note is 1.9.9e.  If I had made the
change, it may have looked different (certainly the comment would be different
;-), but I've found no reason to modify this detail of the logic.

> (Who was the first : egg or chicken ?)
> Logicaly, we should get a string (wgetnstr) by first getting its chars
> (wgetch).
> And I see no dependencies in the makefile ?....

The generated makefile only has header-dependencies - which are needed for
building the library.

The reason for wgetnstr in that context is this:  to make the code act
compatible enough to SVr4 curses, ncurses sets the terminal modes to raw.
(This is in fact documented for X/Open curses - though I haven't revisited
that aspect since 1996, iirc).  Thereafter, the (n)curses library simulates
the various cooked/raw/whatever modes by software.  I believe the reason for
that was originally to avoid problems with flushing the current terminal
state as the modes were switched.

It looks odd - but the wgetnstr is called only if the input buffer is empty.
So the program shouldn't loop unless there's a bug - it should take a different
path through _nc_wgetch() for each level.
 
> I don't understand the _nc_wgetch() code at all, and i don't have historic
> of modifications (and why).
> Perhaps the wgetch() in wgetnstr(..) should be a kgetch() ??? I don't know.

kgetch() is an internal function - not part of the curses API.
 
> ----------------------------------------------------------------------------
> ----
> File  : ncurses/base/lib_addch.c
> 
> Function : render_char() - line 66 - redundant A_ATTRIBUTES
> 
>     /* color in attrs has precedence over bkgrnd */
> ==> a |= (AttrOf(win->_nc_bkgd) & A_ATTRIBUTES) & COLOR_MASK(a);
> Can be
>     a |= (AttrOf(win->_nc_bkgd) & COLOR_MASK(a));

thanks - I see this also in lib_cchar.c
 
> ----------------------------------------------------------------------------
> ----
> File  : ncurses/man/lib_inopts.3x
> 
> Change CS8 by CS7.
> 
> curs_inopts(3X)                                   curs_inopts(3X)
>        ..........................................................
>        Initially, whether the terminal returns 7 or 8 significant
>        bits on input depends on  the  control  mode  of  the  tty
>        driver  [see  termio(7)].  To force 8 bits to be returned,
>        invoke meta(win, TRUE); this is equivalent,  under  POSIX,
>        to  setting the CS8 flag on the terminal.  To force 7 bits
>        to be returned, invoke meta(win, FALSE); this  is  equiva?
> ==>    lent,  under  POSIX, to setting the CS8 flag on the termi?
>        nal.  The window argument, win, is always ignored.  If the
>        ..........................................................

thanks (no disagreement here ;-)

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net