Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 04 3月, 2007 7 次提交
  3. 03 3月, 2007 1 次提交
  5. 02 3月, 2007 6 次提交
  7. 01 3月, 2007 7 次提交
  9. 28 2月, 2007 7 次提交
  11. 27 2月, 2007 3 次提交
    • J
      git-apply: do not fix whitespaces on context lines. · 63e50d49
      由 Junio C Hamano 提交于 
      Internal function apply_line() is called to copy both context lines
and added lines to the output buffer, while possibly fixing the
whitespace breakages depending on --whitespace=strip settings.
However, it did its fix-up on both context lines and added lines.

This resulted in two symptoms:

 (1) The number of lines reported to have been fixed up included
     these context lines.

 (2) However, the lines actually shown were limited to the added
     lines that had whitespace breakages.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      63e50d49
    • J
      diff --cc: integer overflow given a 2GB-or-larger file · ee24ee55
      由 Jim Meyering 提交于 
      Few of us use git to compare or even version-control 2GB files,
but when we do, we'll want it to work.

Reading a recent patch, I noticed two lines like this:

   int len = st.st_size;

Instead of "int", that should be "size_t".  Otherwise, in the
non-symlink case, with 64-bit size_t, if the file's size is 2GB,
the following xmalloc will fail:

   result = xmalloc(len + 1);

trying to allocate 2^64 - 2^31 + 1 bytes (assuming sign-extension
in the int-to-size_t promotion).  And even if it didn't fail, the
subsequent "result[len] = 0;" would be equivalent to an unpleasant
"result[-2147483648] = 0;"

The other nearby "int"-declared size variable, sz, should also be of
type size_t, for the same reason.  If sz ever wraps around and becomes
negative, xread will corrupt memory _before_ the "result" buffer.
Signed-off-by: NJim Meyering <jim@meyering.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      ee24ee55
    • L
      mailinfo: do not get confused with logical lines that are too long. · 34fc5cef
      由 Linus Torvalds 提交于 
      It basically considers all the continuation lines to be lines of their
own, and if the total line is bigger than what we can fit in it, we just
truncate the result rather than stop in the middle and then get confused
when we try to parse the "next" line (which is just the remainder of the
first line).

[jc: added test, and tightened boundary a bit per list discussion.]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      34fc5cef
  13. 26 2月, 2007 9 次提交