1. 08 Oct, 2020 1 commit
    • Improve the support of atomics · cc1d7f5c
      This change:
      
      * Starts using GCC's and clang's `__atomic_*` intrinsics instead of the
        `__sync_*` ones, since the former supercede the latter (and can be
        safely replaced by their equivalent `__atomic_*` version with the
        sequentially consistent model).
      * Makes `git_atomic64`'s value `volatile`. Otherwise, this will make
        ThreadSanitizer complain.
      * Adds ways to load the values from atomics. As it turns out,
        unsynchronized read are okay only in some architectures, but if we
        want to be correct (and make ThreadSanitizer happy), those loads
        should also be performed with the atomic builtins.
      * Fixes two ThreadSanitizer warnings, as a proof-of-concept that this
        works:
        - Avoid directly accessing `git_refcount`'s `owner` directly, and
          instead makes all callers go through the `GIT_REFCOUNT_*()` macros,
          which also use the atomic utilities.
        - Makes `pool_system_page_size()` race-free.
      
      Part of: #5592
      lhchavez committed
  2. 23 Aug, 2019 1 commit
    • util: do not perform allocations in insertsort · 8cbef12d
      Our hand-rolled fallback sorting function `git__insertsort_r` does an
      in-place sort of the given array. As elements may not necessarily be
      pointers, it needs a way of swapping two values of arbitrary size, which
      is currently implemented by allocating a temporary buffer of the
      element's size. This is problematic, though, as the emulated `qsort`
      interface doesn't provide any return values and thus cannot signal an
      error if allocation of that temporary buffer has failed.
      
      Convert the function to swap via a temporary buffer allocated on the
      stack. Like this, it can `memcpy` contents of both elements in small
      batches without requiring a heap allocation. The buffer size has been
      chosen such that in most cases, a single iteration of copying will
      suffice. Most importantly, it can fully contain `git_oid` structures and
      pointers.
      
      Add a bunch of tests for the `git__qsort_r` interface to verify nothing
      breaks. Furthermore, this removes the declaration of `git__insertsort_r`
      and makes it static as it is not used anywhere else.
      Patrick Steinhardt committed
  3. 29 Jul, 2019 1 commit
    • util: use 64 bit timer on Windows · fb0730f1
      git__timer was originally implemented using a 32 bit timer since
      Windows XP did not support GetTickCount64. Windows XP was discontinued
      five years ago, so it should be safe to use the new API.
      
      As a benefit, we do not need to care about overflows for the next 585
      million years.
      Tobias Nießen committed
  4. 16 Apr, 2019 1 commit
    • util: introduce GIT_CONTAINER_OF macro · b5f40441
      In some parts of our code, we make rather heavy use of casting
      structures to their respective specialized implementation. One
      example is the configuration code with the general
      `git_config_backend` and the specialized `diskfile_header`
      structures. At some occasions, it can get confusing though with
      regards to the correct inheritance structure, which led to the
      recent bug fixed in 2424e64c (config: harden our use of the
      backend objects a bit, 2018-02-28).
      
      Object-oriented programming in C is hard, but we can at least try
      to have some checks when it comes to casting around stuff. Thus,
      this commit introduces a `GIT_CONTAINER_OF` macro, which accepts
      as parameters the pointer that is to be casted, the pointer it
      should be cast to as well as the member inside of the target
      structure that is the containing structure. This macro then tries
      hard to detect mis-casts:
      
      - It checks whether the source and target pointers are of the
        same type. This requires support by the compiler, as it makes
        use of the builtin `__builtin_types_compatible_p`.
      
      - It checks whether the embedded member of the target structure
        is the first member. In order to make this a compile-time
        constant, the compiler-provided `__builtin_offsetof` is being
        used for this.
      
      - It ties these two checks together by the compiler-builtin
        `__builtin_choose_expr`. Based on whether the previous two
        checks evaluate to `true`, the compiler will either compile in
        the correct cast, or it will output `(void)0`. The second case
        results in a compiler error, resulting in a compile-time check
        for wrong casts.
      
      The only downside to this is that it relies heavily on
      compiler-specific extensions. As both GCC and Clang support these
      features, only define this macro like explained above in case
      `__GNUC__` is set (Clang also defines `__GNUC__`). If the
      compiler is not Clang or GCC, just go with a simple cast without
      any additional checks.
      Patrick Steinhardt committed
  5. 29 Mar, 2019 1 commit
  6. 25 Oct, 2018 1 commit
    • util: provide `git__memmem` function · 83e8a6b3
      Unfortunately, neither the `memmem` nor the `strnstr` functions are part
      of any C standard but are merely extensions of C that are implemented by
      e.g. glibc. Thus, there is no standardized way to search for a string in
      a block of memory with a limited size, and using `strstr` is to be
      considered unsafe in case where the buffer has not been sanitized. In
      fact, there are some uses of `strstr` in exactly that unsafe way in our
      codebase.
      
      Provide a new function `git__memmem` that implements the `memmem`
      semantics. That is in a given haystack of `n` bytes, search for the
      occurrence of a byte sequence of `m` bytes and return a pointer to the
      first occurrence. The implementation chosen is the "Not So Naive"
      algorithm from [1]. It was chosen as the implementation is comparably
      simple while still being reasonably efficient in most cases.
      Preprocessing happens in constant time and space, searching has a time
      complexity of O(n*m) with a slightly sub-linear average case.
      
      [1]: http://www-igm.univ-mlv.fr/~lecroq/string/
      Patrick Steinhardt committed
  7. 18 Oct, 2018 2 commits
    • util: remove `git__strtol32` · 8d7fa88a
      The function `git__strtol32` can easily be misused when untrusted data
      is passed to it that may not have been sanitized with trailing `NUL`
      bytes. As all usages of this function have now been removed, we can
      remove this function altogether to avoid future misuse of it.
      Patrick Steinhardt committed
    • util: remove unsafe `git__strtol64` function · 68deb2cc
      The function `git__strtol64` does not take a maximum buffer length as
      parameter. This has led to some unsafe usages of this function, and as
      such we may consider it as being unsafe to use. As we have now
      eradicated all usages of this function, let's remove it completely to
      avoid future misuse.
      Patrick Steinhardt committed
  8. 07 Jun, 2018 3 commits
    • util: extract allocators into its own "alloc.h" header · d2e996fa
      Our "util.h" header is a grabbag of various different functions, where
      many don't have a clear group they belong to. Our set of allocator
      functions though can be clearly singled out as a single group of
      functions that always belongs together. Furthermore, we will need to
      implement additional functions relating to our allocators subsystem when
      moving to pluggable allocators. Thus, we should just move these
      functions into their own "alloc" module.
      Patrick Steinhardt committed
    • util: extract `stdalloc` allocator into its own module · c47f7155
      Right now, the standard allocator is being declared as part of the
      "util.h" header as a set of inline functions. As with the crtdbg
      allocator functions, these inline functions make it hard to convert to
      function pointers for our allocators.
      
      Create a new "stdalloc" module containing our standard allocations
      functions to split these out. Convert the existing allocators to macros
      which make use of the stdalloc functions.
      Patrick Steinhardt committed
    • win32: crtdbg: provide independent `free` function · 496b0df2
      Currently, the `git__free` function is being defined in a single place,
      only, disregarding whether we use our standard allocators or the crtdbg
      allocators. This makes it a bit harder to convert our code base to use
      pluggable allocators, and furthermore makes the border between our two
      allocators a bit more blurry.
      
      Implement a separate `git__crtdbg__free` function for the crtdbg
      allocator in order to completely separate both allocator
      implementations.
      Patrick Steinhardt committed
  9. 05 May, 2018 1 commit
  10. 16 Feb, 2018 1 commit
    • util: clean up header includes · 92324d84
      While "util.h" declares the macro `git__tolower`, which simply resorts
      to tolower(3P) on Unix-like systems, the <ctype.h> header is only being
      included in "util.c". Thus, anybody who has included "util.h" without
      having <ctype.h> included will fail to compile as soon as the macro is
      in use.
      
      Furthermore, we can clean up additional includes in "util.c" and simply
      replace them with an include for "common.h".
      Patrick Steinhardt committed
  11. 01 Feb, 2018 1 commit
  12. 20 Dec, 2017 1 commit
    • util: introduce `git__prefixncmp` and consolidate implementations · 86219f40
      Introduce `git_prefixncmp` that will search up to the first `n`
      characters of a string to see if it is prefixed by another string.
      This is useful for examining if a non-null terminated character
      array is prefixed by a particular substring.
      
      Consolidate the various implementations of `git__prefixcmp` around a
      single core implementation and add some test cases to validate its
      behavior.
      Edward Thomson committed
  13. 18 Nov, 2017 1 commit
    • refcount: make refcounting conform to aliasing rules · 585b5dac
      Strict aliasing rules dictate that for most data types, you are not
      allowed to cast them to another data type and then access the casted
      pointers. While this works just fine for most compilers, technically we
      end up in undefined behaviour when we hurt that rule.
      
      Our current refcounting code makes heavy use of casting and thus
      violates that rule. While we didn't have any problems with that code,
      Travis started spitting out a lot of warnings due to a change in their
      toolchain. In the refcounting case, the code is also easy to fix:
      as all refcounting-statements are actually macros, we can just access
      the `rc` field directly instead of casting.
      
      There are two outliers in our code where that doesn't work. Both the
      `git_diff` and `git_patch` structures have specializations for generated
      and parsed diffs/patches, which directly inherit from them. Because of
      that, the refcounting code is only part of the base structure and not of
      the children themselves. We can help that by instead passing their base
      into `GIT_REFCOUNT_INC`, though.
      Patrick Steinhardt committed
  14. 03 Jul, 2017 2 commits
    • Make sure to always include "common.h" first · 0c7f49dd
      Next to including several files, our "common.h" header also declares
      various macros which are then used throughout the project. As such, we
      have to make sure to always include this file first in all
      implementation files. Otherwise, we might encounter problems or even
      silent behavioural differences due to macros or defines not being
      defined as they should be. So in fact, our header and implementation
      files should make sure to always include "common.h" first.
      
      This commit does so by establishing a common include pattern. Header
      files inside of "src" will now always include "common.h" as its first
      other file, separated by a newline from all the other includes to make
      it stand out as special. There are two cases for the implementation
      files. If they do have a matching header file, they will always include
      this one first, leading to "common.h" being transitively included as
      first file. If they do not have a matching header file, they instead
      include "common.h" as first file themselves.
      
      This fixes the outlined problems and will become our standard practice
      for header and source files inside of the "src/" from now on.
      Patrick Steinhardt committed
    • Fix missing include for header files · 0fb4b351
      Some of our header files are not included at all by any of their
      implementing counter-parts. Including them inside of these files leads
      to some compile errors mostly due to unknown types because of missing
      includes. But there's also one case where a declared function does not
      match the implementation's prototype.
      
      Fix all these errors by fixing up the prototype and adding missing
      includes. This is preparatory work for fixing up missing includes in the
      implementation files.
      Patrick Steinhardt committed
  15. 30 Jun, 2017 1 commit
    • win32: fix circular include deps with w32_crtdbg · 459fb8fe
      The current order of declarations and includes between "common.h" and
      "w32_crtdbg_stacktrace.h" is rather complicated. Both header files make
      use of things defined in the other one and are thus circularly dependent
      on each other. This makes it currently impossible to compile the
      "w32_crtdbg_stacktrace.c" file when including "common.h" inside of
      "w32_crtdbg_stacktrace.h".
      
      We can disentangle the mess by moving declaration of the inline crtdbg
      functions into the "w32_crtdbg_stacktrace.h" file and adding additional
      includes inside of it, such that all required functions are available to
      it. This allows us to break the dependency cycle.
      Patrick Steinhardt committed
  16. 26 May, 2016 1 commit
  17. 02 Jul, 2015 1 commit
  18. 29 Jun, 2015 1 commit
  19. 29 May, 2015 1 commit
    • git__tolower: a tolower() that isn't dumb · 75a4636f
      Some brain damaged tolower() implementations appear to want to
      take the locale into account, and this may require taking some
      insanely aggressive lock on the locale and slowing down what should
      be the most trivial of trivial calls for people who just want to
      downcase ASCII.
      Edward Thomson committed
  20. 15 Apr, 2015 1 commit
  21. 13 Feb, 2015 6 commits
  22. 15 Jan, 2015 1 commit
  23. 28 Dec, 2014 1 commit
  24. 23 Dec, 2014 1 commit
    • don't treat 0x85 as whitespace · fe5f7722
      A byte value of 0x85 is not whitespace, we were conflating that with
      U+0085 (UTF8: 0xc2 0x85).  This caused us to incorrectly treat valid
      multibyte characters like U+88C5 (UTF8: 0xe8 0xa3 0x85) as whitespace.
      Edward Thomson committed
  25. 16 Dec, 2014 2 commits
    • checkout: disallow bad paths on win32 · a64119e3
      Disallow:
       1. paths with trailing dot
       2. paths with trailing space
       3. paths with trailing colon
       4. paths that are 8.3 short names of .git folders ("GIT~1")
       5. paths that are reserved path names (COM1, LPT1, etc).
       6. paths with reserved DOS characters (colons, asterisks, etc)
      
      These paths would (without \\?\ syntax) be elided to other paths - for
      example, ".git." would be written as ".git".  As a result, writing these
      paths literally (using \\?\ syntax) makes them hard to operate with from
      the shell, Windows Explorer or other tools.  Disallow these.
      Edward Thomson committed
  26. 05 Aug, 2014 1 commit
  27. 31 May, 2014 1 commit
  28. 02 May, 2014 2 commits
  29. 23 Apr, 2014 1 commit