Re: A Valgrind-observant ncurses

[Thomas Dickey]

On Thu, Jun 20, 2024 at 01:06:54PM -0400, Bill Gray wrote:
> Hi Branden,  all,
> 
> On 6/20/24 11:12, G. Branden Robinson wrote:
> > Hi Bill,
> > >     ...It's five blocks unless printw() is called;  apparently,
> > >     that function maintains a static buffer that isn't freed.
> > 
> > What do you mean by "static" here?
> 
>    Sorry,  I was sloppy in my language there.  You're right;  a 'static
> buffer' should be assumed to be one declared as,  say,
> 
> static char buffer[80];
> 
>    What I meant was that you have a buffer that is allocated when printw()
> is first called,  and possibly resized if it needs to be made larger.  On
> the first call to printw(),  it might allocate an 80 byte buffer,  figuring
> that'll be big enough 99% of the time.   Then,  when it encounters a
> printw() that requires 200 bytes,  the buffer is re-allocated to be (say)
> 300 bytes.  Subsequent calls may exceed even that limit,  and cause the
> buffer to be re-re-allocated to be still larger.
> 
>    Ideally,  the buffer is then freed when endwin() or delscreen() is
> called.  Except that doesn't happen here.

It shouldn't, because curses guarantees that you can do a refresh after
endwin and get the screen contents as they were.

ncurses used to use setbuf, which entails its own limitations
(you can NOT free its buffer), but that got in the way of handling signals.

ncurses could free its own I/O buffer, but since it needs other memory
to persist, that would be kind of pointless.
 
-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

signature.asc
Description: PGP signature