On Jan 22, 2015, at 11:23, Junio C Hamano wrote:
"Kyle J. McKay" <mack...@gmail.com> writes:
On Jan 21, 2015, at 14:33, Junio C Hamano wrote:
"Kyle J. McKay" <mack...@gmail.com> writes:
So since I've not been able to get test 2 or 3 to core dump (even
before 250b3c6c) I tend to believe you are correct in that the code
thinks (incorrectly) that the result should fit within the buffer.
Thanks; let me steal your tests when I reroll.
Awesome. :)
But please squash in this tiny change if using the tests verbatim:
Thanks. I actually have a question wrt the need for $MAKE_PATCHES.
It would have been more natural to do something like:
test_expect_success 'setup' '
printf "\t%s\n" 1 2 3 4 5 6 >before &&
printf "\t%s\n" 1 2 3 >after &&
printf "%64s\n" a b c >>after &&
printf "\t%s\n" 4 5 6 >>after &&
git diff --no-index before after |
sed -e "s/before/test-1/" -e "s/after/test-1/" >patch1.patch &&
printf "%64s\n" 1 2 3 4 5 6 >test-1 &&
printf "%64s\n" 1 2 3 a b c 4 5 6 >expect-1 &&
printf "\t%s\n" a b c d e f >before &&
printf "\t%s\n" a b c >after &&
...
cat test-4 >expect-4 &&
printf "%64s\n" a b c >>expect-4 &&
while test $x -lt 100
do
printf "%63s%02d\n" "" $x >>test-4
printf "%63s%02d\n" "" $x >>expect-4
x=$(( $x + 1 ))
done &&
git config core.whitespace tab-in-indent,tabwidth=63 &&
git config apply.whitespace fix
'
test_expect_success 'apply with ws expansion (1)' '
git apply patch1.patch &&
test_cmp test-1 expect-1
'
and if you want test files you can just skip tests #2 and later,
without introducing an ad-hoc mechanism like you did.
Was there something more than that that you wanted from
$MAKE_PATCHES?
Well, see I found t/t4135/make-patches that makes patches for use by
t4135-apply-weird-filenames.sh and thought perhaps that was the
approved way to do things.
But then it seemed overkill since making the patches takes so little
time it didn't seem to warrant a separate directory. But the ability
to just make the patch files without requiring any external scripts or
test framework seemed nice so I added those two extra lines to make it
possible.
I don't have any strong feelings about it. The setup test plus 4
explicit tests looks fine.
In any case, here is an update to that sanity check patch to catch
the two cases the BUG did not trigger.
Sometimes the caller under-counted the size of the result but
thought that it would still fit within the original (hence allowing
us to update in-place by passing postlen==0) but the actual result
was larger than the space we have allocated in the postimage,
clobbering the piece of memory after the postimage->buf.
diff --git a/builtin/apply.c b/builtin/apply.c
index 31f8733..3b7ba63 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -2171,6 +2171,12 @@ static void update_pre_post_images(struct
image *preimage,
ctx++;
}
+ if (postlen
+ ? postlen < new - postimage->buf
+ : postimage->len < new - postimage->buf)
+ die("BUG: caller miscounted postlen: asked %d, orig = %d, used =
%d",
+ (int)postlen, (int) postimage->len, (int)(new - postimage-
>buf));
+
/* Fix the length of the whole thing */
postimage->len = new - postimage->buf;
postimage->nr -= reduced;
Nice. No more of those bogus results can slip through that somehow
evade evoking a core dump.
-Kyle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
