Re: Question about the winch function change (5.2 - 5.3)

[Thomas Dickey]

On Wed, 19 Jan 2005, James Long wrote:

> Greetings,
> I hope this is the correct place to send this email to.  Our software uses
> ncurses and is running on a redhat enterprise server (fully patched), and
> between 5.2 and 5.3, the winch function in ncurses changed.  It used to return
> the chtype of the current character position, now it returns
>    returnChar(CharOf(win->_line[win->_cury].text[win->_curx])  |
> AttrOf(win->_line[win->_cury].text[win->_curx]));
>
> For some reason, the above code returns a different value than the original:
>    returnChar(win->_line[win->_cury].text[win->_curx]);
>
> It only appears to do this on the alternate character set.  For testing, I

That's a clue.  Perhaps you're looking in the wrong place.  Or (given that 
it's Redhat), the "5.3" is one of the later development versions.  I 
modified the storage for alternate characters around the end of 2002 
(after 5.3 release) to resolve some problems with the wide-character 
support (that's a long story).  I don't recall at this moment the whole 
series of changes, but the WINDOW's contents differ, so winch would return 
a different value.  Ultimately the changes mean that the screen contents 
store the literal value such as

#define ACS_BLOCK       NCURSES_ACS('0') /* solid square block */

would store a '0' and A_ALTCHARSET, rather than the mapped value.

Here's a relevant item from lib_acs.c's log:

revision 1.25
date: 2002/12/28 16:26:46;  author: tom;  state: Exp;  lines: +60 -80
first cut of rewrite so SP->_acs_map[] stores the actual mapping, and
acs_map[] just a fake map used to tie-in.  That means that SP->_acs_map[]
will only have A_ALTCHARSET bit set when we "need" to shift-out, and we
can test that in PutAttrChar() to work around Linux console line-drawing
in UTF-8 locale.

> changed the function winch in the 5.3 source from
>    returnChar(CharOf(win->_line[win->_cury].text[win->_curx]) |
>           AttrOf(win->_line[win->_cury].text[win->_curx]));
> to:
>    returnChar(win->_line[win->_cury].text[win->_curx]);
>
> And did a full build (./configure --with-shared, make, make install).  With
> the change, the winch function returns, for example, 6292187, whereas the
> original 5.3 code returns 6292016.  I am not sure how the function can return

6292187 030001333 0x6002db
6292016 030001060 0x600230

I don't see a pattern either, except that the 8 bits for the character 
part differ.  It doesn't look like a sign-extension problem, for instance.

> two different numbers, as the 5.3 code just returns the &'ed chtype with it's
> values
> #define ChCharOf(c)    ((c) & (chtype)A_CHARTEXT)
> #define ChAttrOf(c)     ((c) & (chtype)A_ATTRIBUTES)

It is split up that way so the same source can be used for the 8-bit and 
wide-character configurations.  The latter stores the character and 
attribute in different places.  But as you note, it should be the same 
result.

> When, in my code, I  call my functions (ch is declared as a chtype):
>           ch = mvwinch( pwin, r, c );
>           setattrs( ch & (chtype)A_ATTRIBUTES );
>           paddescch( ch & (chtype)A_CHARTEXT );
>
> The paddescch function (which just prints the character to an output stream)
> doesn't work correctly, as the number (which maps to a character) in the 5.3
> code is 48, whereas in the 5.2 code it is 219 (which makes it work the way it
> used to).
>
> Are there any known bugs with winch, or did I do a horrible job of explaining
> what my problem is and just confuse everyone?

There's enough information, I think.

> Oh, also, this is for a C program, not C++ if that makes any difference, and I
> don't configure with --enable-widec.
>
> Thank you,
>
> James Long
> (888) 923-8368 ext. 2220
> Fax (310) 241-0011
> Advent Resources, Inc
>
>
> _______________________________________________
> Bug-ncurses mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-ncurses

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net