1. 10 Jun, 2018 1 commit
  2. 16 Feb, 2018 1 commit
    • Explicitly mark fallthrough cases with comments · 06b8a40f
      A lot of compilers nowadays generate warnings when there are cases in a
      switch statement which implicitly fall through to the next case. To
      avoid this warning, the last line in the case that is falling through
      can have a comment matching a regular expression, where one possible
      comment body would be `/* fall through */`.
      
      An alternative to the comment would be an explicit attribute like e.g.
      `[[clang::fallthrough]` or `__attribute__ ((fallthrough))`. But GCC only
      introduced support for such an attribute recently with GCC 7. Thus, and
      also because the fallthrough comment is supported by most compilers, we
      settle for using comments instead.
      
      One shortcoming of that method is that compilers are very strict about
      that. Most interestingly, that comment _really_ has to be the last line.
      In case a closing brace follows the comment, the heuristic will fail.
      Patrick Steinhardt committed
  3. 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
  4. 11 Nov, 2017 7 commits
    • patch_parse: allow parsing ambiguous patch headers · 80226b5f
      The git patch format allows for having unquoted paths with whitespaces
      inside. This format becomes ambiguous to parse, e.g. in the following
      example:
      
          diff --git a/file b/with spaces.txt b/file b/with spaces.txt
      
      While we cannot parse this in a correct way, we can instead use the
      "---" and "+++" lines to retrieve the file names, as the path is not
      followed by anything here but spans the complete remaining line. Because
      of this, we can simply bail outwhen parsing the "diff --git" header here
      without an actual error and then proceed to just take the paths from the
      other headers.
      Patrick Steinhardt committed
    • patch_parse: treat complete line after "---"/"+++" as path · 3892f70d
      When parsing the "---" and "+++" line, we stop after the first
      whitespace inside of the filename. But as files containing whitespaces
      do not need to be quoted, we should instead use the complete line here.
      
      This fixes parsing patches with unquoted paths with whitespaces.
      Patrick Steinhardt committed
    • parse: always initialize line pointer · 7bdfc0a6
      Upon initializing the parser context, we do not currently initialize the
      current line, line length and line number. Do so in order to make the
      interface easier to use and more obvious for future consumers of the
      parsing API.
      Patrick Steinhardt committed
    • parse: implement `git_parse_peek` · e72cb769
      Some code parts need to inspect the next few bytes without actually
      consuming it yet, for example to examine what content it has to expect
      next. Create a new function `git_parse_peek` which returns the next byte
      without modifying the parsing context and use it at multiple call sites.
      Patrick Steinhardt committed
    • parse: implement and use `git_parse_advance_digit` · 252f2eee
      The patch parsing code has multiple recurring patterns where we want to
      parse an actual number. Create a new function `git_parse_advance_digit`
      and use it to avoid code duplication.
      Patrick Steinhardt committed
    • patch_parse: use git_parse_contains_s · 65dcb645
      Instead of manually checking the parsing context's remaining length and
      comparing the leading bytes with a specific string, we can simply re-use
      the function `git_parse_ctx_contains_s`. Do so to avoid code duplication
      and to further decouple patch parsing from the parsing context's struct
      members.
      Patrick Steinhardt committed
    • parse: extract parse module · ef1395f3
      The `git_patch_parse_ctx` encapsulates both parser state as well as
      options specific to patch parsing. To advance this state and keep it
      consistent, we provide a few functions which handle advancing the
      current position and accessing bytes of the patch contents. In fact,
      these functions are quite generic and not related to patch-parsing by
      themselves. Seeing that we have similar logic inside of other modules,
      it becomes quite enticing to extract this functionality into its own
      parser module.
      
      To do so, we create a new module `parse` with a central struct called
      `git_parse_ctx`. It encapsulates both the content that is to be parsed
      as well as its lengths and the current position. `git_patch_parse_ctx`
      now only contains this `parse_ctx` only, which is then accessed whenever
      we need to touch the current parser. This is the first step towards
      re-using this functionality across other modules which require parsing
      functionality and remove code-duplication.
      Patrick Steinhardt committed
  5. 01 Sep, 2017 1 commit
  6. 25 Aug, 2017 1 commit
    • patch_parse: implement state machine for parsing patch headers · 57bc9dab
      Our code parsing Git patch headers is rather lax in parsing headers of a
      Git-style patch. Most notably, we do not care for the exact order in
      which header lines appear and as such, we may parse patch files which
      are not really valid after all. Furthermore, the state transitions
      inside of the parser are not as obvious as they could be, making it
      harder than required to follow its logic.
      
      To improve upon this situation, this patch introduces a real state
      machine to parse the patches. Instead of simply parsing each line
      without caring for previous state and the exact ordering, we define a
      set of states with their allowed transitions. This makes the patch
      parser more strict in only allowing valid successions of header lines.
      As the transition table is defined inside of a single structure with
      the expected line, required state as well as the state that we end up
      in, all state transitions are immediately obvious from just having a
      look at this structure. This improves both maintainability and eases
      reasoning about the patch parser.
      Patrick Steinhardt committed
  7. 03 Jul, 2017 1 commit
    • 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
  8. 21 Mar, 2017 1 commit
  9. 14 Mar, 2017 1 commit
    • patch_parse: fix parsing minimal trailing diff line · ad5a909c
      In a diff, the shortest possible hunk with a modification (that is, no
      deletion) results from a file with only one line with a single character
      which is removed. Thus the following hunk
      
          @@ -1 +1 @@
          -a
          +
      
      is the shortest valid hunk modifying a line. The function parsing the
      hunk body though assumes that there must always be at least 4 bytes
      present to make up a valid hunk, which is obviously wrong in this case.
      The absolute minimum number of bytes required for a modification is
      actually 2 bytes, that is the "+" and the following newline. Note: if
      there is no trailing newline, the assumption will not be offended as the
      diff will have a line "\ No trailing newline" at its end.
      
      This patch fixes the issue by lowering the amount of bytes required.
      Patrick Steinhardt committed
  10. 15 Nov, 2016 1 commit
  11. 14 Nov, 2016 1 commit
  12. 05 Sep, 2016 1 commit
  13. 24 Aug, 2016 1 commit
  14. 03 Aug, 2016 1 commit
  15. 24 Jul, 2016 1 commit
  16. 26 Jun, 2016 2 commits
  17. 26 May, 2016 17 commits