Re: [PATCH] sha1_file: don't malloc the whole compressed result when writing out objects
flat view
From: Junio C Hamano <hidden>
Date: 2016-08-13 23:25:32
Nicolas Pitre [off-list ref] writes:
quoted hunk
/* Then the data itself.. */ stream.next_in = buf; stream.avail_in = len; do { + unsigned char *in0 = stream.next_in; ret = deflate(&stream, Z_FINISH); + git_SHA1_Update(&c, in0, stream.next_in - in0);
Actually, I have to take my earlier comment back. This is not "paranoia". I do not see anything that protects the memory area between in0 and stream.next_in from getting modified while deflate() nor SHA1_Update() run from the outside. Unless you copy the data away to somewhere stable at the beginning of each iteration of this loop and run deflate() and SHA1_Update(), you cannot have "paranoia". My comment about "trickier" is about determining the size of that buffer used as "somewhere stable".