1. 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
  2. 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
  3. 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
  4. 05 May, 2018 1 commit
  5. 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
  6. 01 Feb, 2018 1 commit
  7. 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
  8. 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
  9. 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
  10. 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
  11. 26 May, 2016 1 commit
  12. 02 Jul, 2015 1 commit
  13. 29 Jun, 2015 1 commit
  14. 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
  15. 15 Apr, 2015 1 commit
  16. 13 Feb, 2015 6 commits
  17. 15 Jan, 2015 1 commit
  18. 28 Dec, 2014 1 commit
  19. 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
  20. 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
  21. 05 Aug, 2014 1 commit
  22. 31 May, 2014 1 commit
  23. 02 May, 2014 2 commits
  24. 23 Apr, 2014 1 commit
  25. 17 Apr, 2014 1 commit
    • Decouple index iterator sort from index · 3b4c401a
      This makes the index iterator honor the GIT_ITERATOR_IGNORE_CASE
      and GIT_ITERATOR_DONT_IGNORE_CASE flags without modifying the
      index data itself.  To take advantage of this, I had to export a
      number of the internal index entry comparison functions.  I also
      wrote some new tests to exercise the capability.
      Russell Belfer committed
  26. 11 Apr, 2014 1 commit
  27. 05 Feb, 2014 2 commits
  28. 01 Oct, 2013 1 commit