[BUG] wprintw insufficient internal buffer

[Андрей Стоцкий]

I think, I might have found a bug in wprintw and similar functions. Either 
that, or there is an extremely poorly documented edge case to wprintw.
 
>From my testing, it seems to me, that wprintw and other formatting functions 
>are internally allocating a buffer of size LINES * (COLS+1).
Normally, this would be okay, since such a large print would fill up the screen 
and be truncated. However, I've found 2 cases where this behaviour leads to 
unexpected results.
 
1) If scrollok(win, true) was previously called, the output of wprintw is now 
getting scrolled instead of cut off by the screen, which reveals the 
insufficient buffer.
 
2) If the "win" passed to wprintw is a pad (newpad(3)) larger than the screen, 
the internal buffer size is still based on the actual screen size and so the 
output is truncated.
 
Here's a MWE of the first case:
```c
#include <stdlib.h>
#include <ncurses.h>
 
int main(void)
{
    WINDOW *win = initscr();
    scrollok(win, true);
    int h = LINES;
    int w = COLS + 1;
    int size = h * w;
    size += 1; // <- try commenting this line
 
    char *big_buffer = malloc(1+size);
    for (int i = 0; i < size; ++i) {
        big_buffer[i] = '#';
    }
    big_buffer[size-1] = '!';
    big_buffer[size] = '\0';
    mvwprintw(win, 0, 0, "%s\n", big_buffer);
    wgetch(win);
    endwin();
}
```
When the "size += 1" line is commented out, the big_buffer string barely fits 
inside the allocated buffer and so you can see, that the last printed char is 
"!".
If you uncomment the "size += 1" line, then the "!" gets dropped due to the 
wprintw buffer being too small to fit the resulting string.
 
-- 
RuRo, Andrey Stotskiy
ruro.ruro@ya.ru