Re: A Valgrind-observant ncurses

[G. Branden Robinson]

Hi Bill,

At 2024-06-20T10:01:17-0400, Bill Gray wrote:
> https://www.projectpluto.com/temp/ncurses.log
> 
>    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?  My training and experience in C is
that a "static buffer" is one that is "statically" allocated, that is at
compile time, and in object files traditionally appears in a ".data" or
".bss" segment--the latter if initialized zero/empty (cf. ".text", and
".rodata" segments).

Memory can't leak from static allocations because they are of fixed
size.  Only dynamic, a.k.a. run-time allocations, can do so.  So if
printw() is using a static buffer, I'm wondering why Valgrind complains
about it at all.

But from what I see in the aforementioned log file, printw() (an
ncurses function) doesn't only use static buffers; it calls an internal
function _nc_printf_string_sp() which in turn calls malloc()--in other
words, a dynamic memory allocation.

Quite possible there's something about valgrind's diagnostics I don't
understand here.

Meanwhile, is the OP familiar with the `--disable-leaks` flag ncurses
offers in its "configure" script?

INSTALL:
    --disable-leaks
        For testing, compile-in code that frees memory that normally would not
        be freed, to simplify analysis of memory-leaks.

        Any implementation of curses must not free the memory associated with
        a screen, since (even after calling endwin()), it must be available
        for use in the next call to refresh().  There are also chunks of
        memory held for performance reasons.  That makes it hard to analyze
        curses applications for memory leaks.  To work around this, build a
        debugging version of the ncurses library which frees those chunks
        which it can, and provides the _nc_free_and_exit() function to free
        the remainder and then exit.  The ncurses utility and test programs
        use this feature, e.g., via the ExitProgram() macro.

        Because this lies outside of the library's intended usage, it is not
        normally considered part of the ABI.  If there were some (as yet
        unplanned) extension which frees memory in a manner that would let the
        library resume and reallocate memory, then that would not use a "_nc_"
        prefix.

Regards,
Branden

signature.asc
Description: PGP signature