waddch_literal()

[Sam Varshavchik]

I was using the wide character build of ncurses-5.3 with the electricfence 
memory debugger, when it dumped core in waddch_literal().  A brief 
investigation revealed the following possible explanation:

Consider an 80 character display.  Upon entry to waddch_literal, 
win->_curx=79.

The culprit appears to be the following:

152:    line->text[x++] = ch;
153:    /*
154:     * Provide for multi-column characters
155:     */
156:    if_WIDEC({
157:        if (wcwidth(CharOf(ch)) > 1)
158:            AddAttr(line->text[x++], WA_NAC);
159:    }

In the case where it dumped core:

#0  0x081d370c in waddch_literal (win=0x403dff9c, ch=
       {attr = 0, chars = {38291, 0, 0, 0, 0}})

At line 152, the character is placed into the 79th position, and x is 
incremented to 80.

Now, it appears that this unicode character takes up two character cells, 
according to my wcwidth(), so line 158 appears to try to set line->text[80]. 
The problem appears to be that the array is not big enough for that, so it 
runs off the end of the array.

Well, obviously placing a two-cell character in the last character position 
on the line is not going to work, still a casual inquiry does seem to 
indicate that ncurses tries to do boundary checking in these kinds of cases.

Additionally, I do not know if there are any unicode chars that will claim 
three character cell positions, but the unlikely occurence it might be 
useful to adjust this code to handle very, very wide characters...