1. 21 Feb, 2019 8 commits
    • allocators: extract crtdbg allocator into its own file · 48727e5d
      The Windows-specific crtdbg allocator is currently mixed into the
      crtdbg stacktracing compilation unit, making it harder to find
      than necessary. Extract it and move it into the new "allocators/"
      subdirectory to improve discoverability.
      
      This change means that the crtdbg compilation unit is now
      compiled unconditionally, whereas it has previously only been
      compiled on Windows platforms. Thus we now have additional guards
      around the code so that it will only be compiled if
      GIT_MSVC_CRTDBG is defined. This also allows us to move over the
      fallback-implementation of `git_win32_crtdbg_init_allocator` into
      the same compilation unit.
      Patrick Steinhardt committed
    • allocators: move standard allocator into subdirectory · b63396b7
      Right now, our two allocator implementations are scattered around
      the tree in "stdalloc.h" and "win32/w32_crtdbg_stacktrace.h".
      Start grouping them together in a single directory "allocators/",
      similar to how e.g. our streams are organized.
      Patrick Steinhardt committed
    • Merge pull request #4991 from libgit2/ethomson/inttypes · 9eb098d8
      Remove public 'inttypes.h' header
      Patrick Steinhardt committed
    • Remove public 'inttypes.h' header · 247e6d90
      Remove an `inttypes.h` header that is too large in scope, and far too
      public.
      
      For Visual Studio 2012 and earlier (ie, `_MSC_VER < 1800`), we do need
      to include `stdint.h` in our public headers, for types like `uint32_t`.
      
      Internally, we also need to define `PRId64` as a printf formatting
      string when it is not available.
      Edward Thomson committed
    • Merge pull request #4996 from eaigner/master · 554b3b9a
      Prevent reading out of bounds memory
      Patrick Steinhardt committed
    • tests: apply: verify that we correctly truncate the source buffer · 966b9440
      Previously, we would fail to correctly truncate the source buffer
      if the source has more than one line and ends with a non-newline
      character. In the following call, we thus truncate the source
      string in the middle of the second line. Without the bug fixed,
      we would successfully apply the patch to the source and return
      success. With the overflow being fixed, we should return an
      error now.
      Patrick Steinhardt committed
    • apply: prevent OOB read when parsing source buffer · 014d4955
      When parsing the patch image from a string, we split the string
      by newlines to get a line-based view of it. To split, we use
      `memchr` on the buffer and limit the buffer length by the
      original length provided by the caller. This works just fine for
      the first line, but for every subsequent line we need to actually
      subtract the amount of bytes that we have already read.
      
      The above issue can be easily triggered by having a source buffer
      with at least two lines, where the second line does _not_ end in
      a newline. Given a string "foo\nb", we have an original length of
      five bytes. After having extracted the first line, we will point
      to 'b' and again try to `memchr(p, '\n', 5)`, resulting in an
      out-of-bounds read of four bytes.
      
      Fix the issue by correctly subtracting the amount of bytes
      already read.
      Erik Aigner committed
    • Merge pull request #4987 from lhchavez/fix-odb_otype_fast-leak · 6eb4947d
      Fix a memory leak in odb_otype_fast()
      Patrick Steinhardt committed
  2. 20 Feb, 2019 4 commits
  3. 17 Feb, 2019 8 commits
  4. 16 Feb, 2019 1 commit
  5. 14 Feb, 2019 15 commits
  6. 13 Feb, 2019 2 commits
  7. 12 Feb, 2019 1 commit
  8. 02 Feb, 2019 1 commit