gimpimage-colormap.c valgrind shows uninitialized variable when converting image mode to indexed
To reproduce:
- choose Image>Mode>Indexed, expect "Indexed Color Conversion" dialog
- choose "Convert" button
valgrind gives:
==79== Conditional jump or move depends on uninitialised value(s)
==79== at 0x484ED79: __strlen_sse2 (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==79== by 0x510E567: g_strdup (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.1)
==79== by 0x3F0F25: gimp_palette_add_entry (gimppalette.c:430)
==79== by 0x3B1963: gimp_image_colormap_set_palette_entry.isra.0 (gimpimage-colormap.c:436)
in app/gimpimage-colormap.c:436
static void
gimp_image_colormap_set_palette_entry (GimpImage *image,
const GimpRGB *color,
gint index)
{
GimpImagePrivate *private = GIMP_IMAGE_GET_PRIVATE (image);
GimpRGB black;
gchar name[64];
g_return_if_fail (color != NULL);
gimp_rgb_set (&black, 0, 0, 0);
while (gimp_palette_get_n_colors (private->palette) <= index)
gimp_palette_add_entry (private->palette, index, name, &black);
Here the name variable is uninitialized. Its a local variable, on the stack. It might not be a null-terminated string, but gimp_palette_add_entry goes on to strdup it.
I don't know why the compiler didn't catch this, I thought many of these were found and fixed already. Maybe clang or coverity catches this?
I don't know if it is actually harmful, maybe it just creates palette entries with possibly very long garbage names, on certain platforms in certain conditions.
I discovered this while exploring #8894 (closed), but I don't think it is related or the cause of that issue, because there gimp crashes before you click the "Convert" button.
Possibly needs backport to 2.10?