[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Dickey
Subject: Re: Question about the winch function change (5.2 - 5.3)
Date: Wed, 19 Jan 2005 20:58:47 -0500 (EST)

On Wed, 19 Jan 2005, James Long wrote:

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])  |

For some reason, the above code returns a different value than the original:

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]) |

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
#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

Thomas E. Dickey

reply via email to

[Prev in Thread] Current Thread [Next in Thread]