1. 19 Dec, 2020 2 commits
  2. 18 Dec, 2020 1 commit
  3. 13 Dec, 2020 1 commit
    • Make git__strntol64() ~70%* faster · e99e833f
      This change uses compiler intrinsics to detect overflows instead of
      using divisions to detect potential overflow. This makes the code faster
      and makes it easier to read as a bonus side-effect!
      
      Some of the things this quickens:
      
      * Config parsing.
      * Tree parsing.
      * Smart protocol negotiation.
      
      \* Measured by running `libgit2_clar` with `-fno-optimize-sibling-calls
      -fno-omit-frame-pointer` under `perf(1)`:
      
      ```shell
      $ perf diff --symbols=git__strntol64 --compute=ratio \
        --percentage=absolute baseline.data perf.data
      \# Event 'cycles'
      \#
      \# Baseline           Ratio  Shared Object
      \# ........  ..............  .............
      \#
           0.25%        0.321836  libgit2_clar
      ```
      lhchavez committed
  4. 25 Nov, 2019 1 commit
  5. 21 Oct, 2019 1 commit
    • patch_parse: detect overflow when calculating old/new line position · 37141ff7
      When the patch contains lines close to INT_MAX, then it may happen that
      we end up with an integer overflow when calculating the line of the
      current diff hunk. Reject such patches as unreasonable to avoid the
      integer overflow.
      
      As the calculation is performed on integers, we introduce two new
      helpers `git__add_int_overflow` and `git__sub_int_overflow` that perform
      the integer overflow check in a generic way.
      Patrick Steinhardt committed
  6. 03 Oct, 2019 1 commit
    • commit_list: store in/out-degrees as uint16_t · 5cf17e0f
      The commit list's in- and out-degrees are currently stored as `unsigned
      short`. When assigning it the value of `git_array_size`, which returns
      an `size_t`, this generates a warning on some Win32 platforms due to
      loosing precision.
      
      We could just cast the returned value of `git_array_size`, which would
      work fine for 99.99% of all cases as commits typically have less than
      2^16 parents. For crafted commits though we might end up with a wrong
      value, and thus we should definitely check whether the array size
      actually fits into the field.
      
      To ease the check, let's convert the fields to store the degrees as
      `uint16_t`. We shouldn't rely on such unspecific types anyway, as it may
      lead to different behaviour across platforms. Furthermore, this commit
      introduces a new `git__is_uint16` function to check whether it actually
      fits -- if not, we return an error.
      Patrick Steinhardt committed
  7. 20 Jan, 2019 4 commits
  8. 10 Jan, 2019 1 commit
  9. 09 Jan, 2019 1 commit
  10. 06 Jan, 2019 2 commits
    • Attempt at fixing the MingW64 compilation · b5e8272f
      It seems like MingW64's size_t is defined differently than in Linux.
      lhchavez committed
    • Fix a bunch of warnings · 7b453e7e
      This change fixes a bunch of warnings that were discovered by compiling
      with `clang -target=i386-pc-linux-gnu`. It turned out that the
      intrinsics were not necessarily being used in all platforms! Especially
      in GCC, since it does not support __has_builtin.
      
      Some more warnings were gleaned from the Windows build, but I stopped
      when I saw that some third-party dependencies (e.g. zlib) have warnings
      of their own, so we might never be able to enable -Werror there.
      lhchavez committed
  11. 01 Feb, 2018 1 commit
  12. 23 Jan, 2017 1 commit
  13. 20 Feb, 2015 1 commit
  14. 13 Feb, 2015 3 commits