On Tue, May 17, 2016 at 10:02:22PM +0200, Johannes Sixt wrote: > > Interesting. It replicates out of the box for me. > > "Out of the box" are the magic words. I usually compile with -O0, which > doesn't trigger the valgrind report. Heh, I meant that Noam's test worked out of the box. I also build with -O0. I was able to replicate with different optimization levels. I think the interesting thing here is actually the libc (and therefore possibly your valgrind version). I tried compiling with ASAN and get a color value of "48830". But no ASAN warning! I think what is happening is that we over-allocate the new_columns array based on a power of 2, but only initialize up to num_new_columns. So the off-by-one accesses heap memory that is allocated but which we have never written to. > When I compile with a 3.x based gcc on Windows, I see these warnings: > > CC color.o > color.c: In function 'color_parse_mem': > color.c:203: warning: 'c.value' may be used uninitialized in this function > color.c:203: warning: 'c.blue' may be used uninitialized in this function > color.c:203: warning: 'c.green' may be used uninitialized in this function > color.c:203: warning: 'c.red' may be used uninitialized in this function > > (which triggered my curiosity in this bug report). But they seem to be > unrelated and are most likely false positives. Yeah, I think that's unrelated. I'd be highly distrustful of -Wuninitialized in gcc 3.x. We had to mark quite a few false positives back then, that were later corrected in the 4.x series. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html