- 19 Dec, 2020 2 commits
-
-
As it turns out, the implementation of `git__multiply_int64_overflow` is full of edge cases and tricky arithmetic. That means that it should have unit tests. As a result, a bug in `git__strntol64` was found (and fixed!) in clang+32-bit.
lhchavez committed -
This change should now fix the issue for realsies. `./libgit2_clar -score::strtol` passes on a 32-bit Docker.
lhchavez committed
-
- 18 Dec, 2020 1 commit
-
-
This causes clang to produce an undefined reference to `__mulodi4`. This could be fixed by statically linking some compiler-rt libraries to provide this symbol, but let's first stop the bleeding since doing the correct long-term fix requires some non-trivial CMake knowledge which I lack.
lhchavez committed
-
- 13 Dec, 2020 1 commit
-
-
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
-
- 25 Nov, 2019 1 commit
-
-
Use int64_t internally for type visibility.
Edward Thomson committed
-
- 21 Oct, 2019 1 commit
-
-
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
-
- 03 Oct, 2019 1 commit
-
-
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
-
- 20 Jan, 2019 4 commits
-
-
Correct the documentation on the fallback add/multiply with overflow functions.
Edward Thomson committed -
Windows provides <intsafe.h> which provides "performant" add and multiply with overflow operations. Use them when possible.
Edward Thomson committed -
Edward Thomson committed
-
Use the smallest unsigned type that is equivalent to `size_t` to simplify the conditionals. Error if we're on a system that we believe offers builtins but we cannot determine which one to use.
Edward Thomson committed
-
- 10 Jan, 2019 1 commit
-
-
This change tweaks the macros for git__{add,multiply}_sizet_overflow so that GCC can use them. It also stops using the uadd,umul versions since the add,mul can handle way more cases.
lhchavez committed
-
- 09 Jan, 2019 1 commit
-
-
Less controversial changes together is better.
lhchavez committed
-
- 06 Jan, 2019 2 commits
-
-
It seems like MingW64's size_t is defined differently than in Linux.
lhchavez committed -
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
-
- 01 Feb, 2018 1 commit
-
-
use consistent names for the #include / #define header guard pattern.
Edward Thomson committed
-
- 23 Jan, 2017 1 commit
-
-
Edward Thomson committed
-
- 20 Feb, 2015 1 commit
-
-
Jeff Hostetler committed
-
- 13 Feb, 2015 3 commits
-
-
gcc and clang support __builtin_add_overflow, use it whenever possible, falling back to our naive routines.
Edward Thomson committed -
Make our overflow checking look more like gcc and clang's, so that we can substitute it out with the compiler instrinsics on platforms that support it. This means dropping the ability to pass `NULL` as an out parameter. As a result, the macros also get updated to reflect this as well.
Edward Thomson committed -
Add some helper functions to check for overflow in a type-specific manner.
Edward Thomson committed
-