question about term_names memleak (are this bug really fixed)

[Stanislav Ievlev]

Hello Friends!

In the latest ncurses (20031004) you have said that bug with memory leak in 
_nc_free_termtype fixed. But valgrind (memory leak checker) still tell me:

==29210== 28 bytes in 1 blocks are definitely lost in loss record 2 of 2
==29210==    at 0x134DBA: calloc (vg_replace_malloc.c:273)
==29210==    by 0x804A8F1: read_termtype (read_entry.c:208)
==29210==    by 0x804B382: _nc_read_file_entry (read_entry.c:394)
==29210==    by 0x804B4B0: _nc_read_terminfo_dirs (read_entry.c:440)

Test program was simple:
--
#include <curses.h>
#include <term.h>

main()
{
    setupterm((char *)0, 1, (int *)0);
    if (cur_term) del_curterm(cur_term);
}
--

I compile it in following way:
$gcc -o test test.c libncurses_g.a
$valgrind --show-reachable=yes --leak-check=yes -v ./test 2>log

My question is: why you use so complicated algorithm for freeing of term_names?
Are memory leak still exist or my program is wrong?

There are also other memory leak:

==29210== 24 bytes in 1 blocks are still reachable in loss record 1 of 2
==29210==    at 0x134942: malloc (vg_replace_malloc.c:153)
==29210==    by 0x804BC60: _nc_home_terminfo (home_terminfo.c:56)
==29210==    by 0x804B5CD: _nc_read_entry (read_entry.c:494)
==29210==    by 0x80491C9: grab_entry (lib_setup.c:255)

P.S. Are any mailing list for generic (not a bugs) curses discussion exists? I 
wrote some ncurses based libraries and want to consult with curses guru.

--
With best regards
Stanislav Ievlev

ALT Linux Team.