summaryrefslogtreecommitdiff
path: root/src/integer.h
Commit message (Collapse)AuthorAgeFilesLines
* 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