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 _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
