Re: [PATCH] sha1_file: don't malloc the whole compressed result when writing out objects
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 21, 2010, 22:30 UTC
- Message-ID
- <7v3a0umdb8.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <alpine.LFD.2.00.1002211522120.1946@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
Show 7 quoted lines
> /* 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".