summaryrefslogtreecommitdiff
path: root/src/integer.h
Commit message (Collapse)AuthorAgeFilesLines
* Initial pass at using int64_t instead of long longCalvin Buckley2021-07-061-2/+2
| | | | | | | | | Even on systems without C99 where long long and stdint are both missing, we can shim stdint and point it to any compiler-specific type (i.e long long, _int64, etc.). Also next is constant suffixes and determining what needs to include stdint.
* Add tests for `git__multiply_int64_overflow`lhchavez2020-12-191-5/+37
| | | | | | | | | 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.
* Third attempt to fix the 32-bit version of `git__multiply_int64_overflow`lhchavez2020-12-181-4/+11
| | | | | | This change should now fix the issue for realsies. `./libgit2_clar -score::strtol` passes on a 32-bit Docker.
* Avoid using `__builtin_mul_overflow` with the clang+32-bit combolhchavez2020-12-181-3/+10
| | | | | | | | 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.
* Make git__strntol64() ~70%* fasterlhchavez2020-12-121-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 ```
* integer: use int64_t's for checksEdward Thomson2019-11-251-4/+4
| | | | Use int64_t internally for type visibility.
* patch_parse: detect overflow when calculating old/new line positionPatrick Steinhardt2019-10-211-0/+28
| | | | | | | | | | | 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.
* commit_list: store in/out-degrees as uint16_tPatrick Steinhardt2019-10-031-0/+7
| | | | | | | | | | | | | | | | | | | 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.
* add with overflow: correct documentationethomson/fix-intrinsicsEdward Thomson2019-01-201-2/+2
| | | | | Correct the documentation on the fallback add/multiply with overflow functions.
* add with overflow: use SizeTAdd on WindowsEdward Thomson2019-01-201-0/+10
| | | | | Windows provides <intsafe.h> which provides "performant" add and multiply with overflow operations. Use them when possible.
* Remove unused git__add_uint64_overflowEdward Thomson2019-01-201-12/+0
|
* add with overflow intrinsics: simplify testsEdward Thomson2019-01-201-26/+18
| | | | | | 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.
* Let GCC use the add/mul overflow intrinsicslhchavez2019-01-091-10/+30
| | | | | | | | 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.
* consistent header guardsethomson/header_guardsEdward Thomson2018-02-011-1/+1
| | | | use consistent names for the #include / #define header guard pattern.
* mac: on 32 bit, use `__builtin_umull_overflow`Edward Thomson2017-01-231-6/+6
|
* Fix MAX 32 bit build problem described in libgit2/libgit2#2917ntk/macosx_build_cherrypickedJeff Hostetler2015-02-201-1/+1
|
* integer overflow: use compiler intrinsics if supportedEdward Thomson2015-02-131-0/+15
| | | | | gcc and clang support __builtin_add_overflow, use it whenever possible, falling back to our naive routines.
* Make our overflow check look more like gcc/clang'sEdward Thomson2015-02-131-12/+16
| | | | | | | | | 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.
* Introduce git__add_sizet_overflow and friendsEdward Thomson2015-02-121-0/+77
Add some helper functions to check for overflow in a type-specific manner.
View Lorry Controller Status