One place where there are a lot of calls to the unsafe strcpy() is
epan/column-utils.c. However, before replacing them with g_strpcpy(), I
wanted to ask if there is any reason we can't start using dynamic memory
allocation in those places (as Guy recently suggested) instead of
g_strlcpy()?
We are allocating full field widths worth of memory for every column
(256 bytes each) plus the info column (4096 bytes each) for every row in
the build_column_format_array() function (in epan/column.c) ahead of
time and then strcpy() data into them. With our default number of
columns, that's 5,376 bytes per row! A sample capture file I just
opened would use 49 bytes for the first row (~0.9% of the allocated
space). Worse yet, I haven't found a place where these allocations
(done with g_malloc()) are freed. If they really aren't freed, this
would lead to increasing memory usage every time you close a capture and
open a new one until the program itself was closed.
We would probably need to change all of the column data handling
functions to allocate memory as needed and realloc it if data is
appended. Perhaps we could use g_string_* functions to make that
easier.
Any thoughts?
Steve
