Hi, On Tue, 27 Jan 2009, Mark Brown wrote: > On Tue, Jan 27, 2009 at 05:26:34AM +0100, Johannes Schindelin wrote: > > > I suspected that zlib does something "cute" with alignments, i.e. that > > it writes a possibly odd number of bytes, but then rounds up the > > buffer to the next multiple of two of four bytes. > > I don't recall anything along those lines in zlib but it does generate > warnings with valgrind which require overrides - it has at least one > unrolled loop which roll on beyond initialised memory (but keep within > memory that zlib knows it has allocated). It rolls back the results of > the loop before producing output, but it's possible that some unused > bits in the stream may be derived from the results. That is what I suspected, but the data contradict this: - accesses to all offsets between 0 and 50 and 52 and 58 (one _more_ than indicated as valid by stream.total_count!) do not trigger any message in valgrind. - access to offset 51, which is well _within_ the boundaries, and even well outside the range of a stray alignment issue, _does_ trigger a valgrind message. So either valgrind gets it wrong (which I find rather unlikely), or zlib really does not write to that offset. Or, and I think that makes most sense so far, valgrind has not really ignored the initialization of byte number 52 in that buffer which partly depended on an uninitialized value (but does not matter, maybe due to Huffman cutoff or something similar). Come to think of it, the word "suppression" is probably a good indicator that valgrind never claimed it would mark the zlib buffer as properly initialized. Sorry for the noise, then, Dscho -- 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
