1. 02 Jan, 2019 1 commit
  2. 06 May, 2018 1 commit
    • Johannes Schindelin's avatar
      Replace all die("BUG: ...") calls by BUG() ones · 033abf97
      Johannes Schindelin authored
      In d8193743 (usage.c: add BUG() function, 2017-05-12), a new macro
      was introduced to use for reporting bugs instead of die(). It was then
      subsequently used to convert one single caller in 588a538a
      (setup_git_env: convert die("BUG") to BUG(), 2017-05-12).
      
      The cover letter of the patch series containing this patch
      (cf 20170513032414.mfrwabt4hovujde2@sigill.intra.peff.net) is not
      terribly clear why only one call site was converted, or what the plan
      is for other, similar calls to die() to report bugs.
      
      Let's just convert all remaining ones in one fell swoop.
      
      This trick was performed by this invocation:
      
      	sed -i 's/die("BUG: /BUG("/g' $(git grep -l 'die("BUG' \*.c)
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      033abf97
  3. 22 Feb, 2018 1 commit
  4. 06 Nov, 2017 1 commit
  5. 14 Sep, 2017 1 commit
    • Jeff King's avatar
      avoid "write_in_full(fd, buf, len) != len" pattern · 06f46f23
      Jeff King authored
      The return value of write_in_full() is either "-1", or the
      requested number of bytes[1]. If we make a partial write
      before seeing an error, we still return -1, not a partial
      value. This goes back to f6aa66cb (write_in_full: really
      write in full or return error on disk full., 2007-01-11).
      
      So checking anything except "was the return value negative"
      is pointless. And there are a couple of reasons not to do
      so:
      
        1. It can do a funny signed/unsigned comparison. If your
           "len" is signed (e.g., a size_t) then the compiler will
           promote the "-1" to its unsigned variant.
      
           This works out for "!= len" (unless you really were
           trying to write the maximum size_t bytes), but is a
           bug if you check "< len" (an example of which was fixed
           recently in config.c).
      
           We should avoid promoting the mental model that you
           need to check the length at all, so that new sites are
           not tempted to copy us.
      
        2. Checking for a negative value is shorter to type,
           especially when the length is an expression.
      
        3. Linus says so. In d34cf19b (Clean up write_in_full()
           users, 2007-01-11), right after the write_in_full()
           semantics were changed, he wrote:
      
             I really wish every "write_in_full()" user would just
             check against "<0" now, but this fixes the nasty and
             stupid ones.
      
           Appeals to authority aside, this makes it clear that
           writing it this way does not have an intentional
           benefit. It's a historical curiosity that we never
           bothered to clean up (and which was undoubtedly
           cargo-culted into new sites).
      
      So let's convert these obviously-correct cases (this
      includes write_str_in_full(), which is just a wrapper for
      write_in_full()).
      
      [1] A careful reader may notice there is one way that
          write_in_full() can return a different value. If we ask
          write() to write N bytes and get a return value that is
          _larger_ than N, we could return a larger total. But
          besides the fact that this would imply a totally broken
          version of write(), it would already invoke undefined
          behavior. Our internal remaining counter is an unsigned
          size_t, which means that subtracting too many byte will
          wrap it around to a very large number. So we'll instantly
          begin reading off the end of the buffer, trying to write
          gigabytes (or petabytes) of data.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Reviewed-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      06f46f23
  6. 15 Jun, 2017 1 commit
  7. 30 May, 2017 1 commit
  8. 26 May, 2017 3 commits
  9. 19 Apr, 2017 1 commit
  10. 28 Feb, 2017 2 commits
  11. 11 Jul, 2016 1 commit
  12. 08 Jul, 2016 3 commits
    • Jeff King's avatar
      write_file: add pointer+len variant · 52563d7e
      Jeff King authored
      There are many callsites which could use write_file, but for
      which it is a little awkward because they have a strbuf or
      other pointer/len combo. Specifically:
      
       1. write_file() takes a format string, so we have to use
          "%s" or "%.*s", which are ugly.
      
       2. Using any form of "%s" does not handle embedded NULs in
          the output. That probably doesn't matter for our
          call-sites, but it's nicer not to have to worry.
      
       3. It's less efficient; we format into another strbuf
          just to do the write. That's probably not measurably
          slow for our uses, but it's simply inelegant.
      
      We can fix this by providing a helper to write out the
      formatted buffer, and just calling it from write_file().
      
      Note that we don't do the usual "complete with a newline"
      that write_file does. If the caller has their own buffer,
      there's a reasonable chance they're doing something more
      complicated than a single line, and they can call
      strbuf_complete_line() themselves.
      
      We could go even further and add strbuf_write_file(), but it
      doesn't save much:
      
        -  write_file_buf(path, sb.buf, sb.len);
        +  strbuf_write_file(&sb, path);
      
      It would also be somewhat asymmetric with strbuf_read_file,
      which actually returns errors rather than dying (and the
      error handling is most of the benefit of write_file() in the
      first place).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      52563d7e
    • Jeff King's avatar
      write_file: use xopen · ee861e0f
      Jeff King authored
      This simplifies the code a tiny bit, and provides consistent
      error messages with other users of xopen().
      
      While we're here, let's also switch to using O_WRONLY. We
      know we're only going to open/write/close the file, so
      there's no point in asking for O_RDWR.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ee861e0f
    • Jeff King's avatar
      write_file: drop "gently" form · ef22318c
      Jeff King authored
      There are no callers left of write_file_gently(). Let's drop
      it, as it doesn't seem likely for new callers to be added
      (since its inception, the only callers who wanted the gentle
      form generally just died immediately themselves, and have
      since been converted).
      
      While we're there, let's also drop the "int" return from
      write_file, as it is never meaningful (in the non-gentle
      form, we always either die or return 0).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ef22318c
  13. 27 Jun, 2016 2 commits
    • Eric Wong's avatar
      xwrite: poll on non-blocking FDs · ef1cf016
      Eric Wong authored
      write(2) can hit the same EAGAIN/EWOULDBLOCK errors as read(2),
      so busy-looping on a non-blocking FD is a waste of resources.
      
      Currently, I do not know of a way for this happen:
      
      * the NonBlocking directive in systemd does not apply to stdin,
        stdout, or stderr.
      
      * xinetd provides no way to set the non-blocking flag at all
      
      But theoretically, it's possible a careless C10K HTTP server
      could use pipe2(..., O_NONBLOCK) to setup a pipe for
      git-http-backend with only the intent to use non-blocking reads;
      but accidentally leave non-blocking set on the write end passed
      as stdout to git-upload-pack.
      
      Followup-to: 1079c4be ("xread: poll on non blocking fds")
      Signed-off-by: default avatarEric Wong <e@80x24.org>
      Reviewed-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ef1cf016
    • Eric Wong's avatar
      xread: retry after poll on EAGAIN/EWOULDBLOCK · c22f6202
      Eric Wong authored
      We should continue to loop after EAGAIN/EWOULDBLOCK as the
      intent of xread is to try until there is available data,
      EOF, or an unrecoverable error.
      
      Fixes: 1079c4be ("xread: poll on non blocking fds")
      Signed-off-by: default avatarEric Wong <e@80x24.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c22f6202
  14. 09 May, 2016 1 commit
  15. 22 Apr, 2016 1 commit
  16. 22 Feb, 2016 1 commit
    • Jeff King's avatar
      harden REALLOC_ARRAY and xcalloc against size_t overflow · e7792a74
      Jeff King authored
      REALLOC_ARRAY inherently involves a multiplication which can
      overflow size_t, resulting in a much smaller buffer than we
      think we've allocated. We can easily harden it by using
      st_mult() to check for overflow.  Likewise, we can add
      ALLOC_ARRAY to do the same thing for xmalloc calls.
      
      xcalloc() should already be fine, because it takes the two
      factors separately, assuming the system calloc actually
      checks for overflow. However, before we even hit the system
      calloc(), we do our memory_limit_check, which involves a
      multiplication. Let's check for overflow ourselves so that
      this limit cannot be bypassed.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      e7792a74
  17. 07 Jan, 2016 1 commit
  18. 16 Dec, 2015 1 commit
    • Stefan Beller's avatar
      xread: poll on non blocking fds · 1079c4be
      Stefan Beller authored
      The man page of read(2) says:
      
        EAGAIN The file descriptor fd refers to a file other than a socket
      	 and has been marked nonblocking (O_NONBLOCK), and the read
      	 would block.
      
        EAGAIN or EWOULDBLOCK
      	 The file descriptor fd refers to a socket and has been marked
      	 nonblocking (O_NONBLOCK), and the read would block.  POSIX.1-2001
      	 allows either error to be returned for this case, and does not
      	 require these constants to have the same value, so a portable
      	 application should check for both possibilities.
      
      If we get an EAGAIN or EWOULDBLOCK the fd must have set O_NONBLOCK.
      As the intent of xread is to read as much as possible either until the
      fd is EOF or an actual error occurs, we can ease the feeder of the fd
      by not spinning the whole time, but rather wait for it politely by not
      busy waiting.
      
      We should not care if the call to poll failed, as we're in an infinite
      loop and can only get out with the correct read().
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Acked-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      1079c4be
  19. 10 Dec, 2015 1 commit
  20. 25 Sep, 2015 1 commit
    • Jeff King's avatar
      add xsnprintf helper function · 7b03c89e
      Jeff King authored
      There are a number of places in the code where we call
      sprintf(), with the assumption that the output will fit into
      the buffer. In many cases this is true (e.g., formatting a
      number into a large buffer), but it is hard to tell
      immediately from looking at the code. It would be nice if we
      had some run-time check to make sure that our assumption is
      correct (and to communicate to readers of the code that we
      are not blindly calling sprintf, but have actually thought
      about this case).
      
      This patch introduces xsnprintf, which behaves just like
      snprintf, except that it dies whenever the output is
      truncated. This acts as a sort of assert() for these cases,
      which can help find places where the assumption is violated
      (as opposed to truncating and proceeding, which may just
      silently give a wrong answer).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      7b03c89e
  21. 25 Aug, 2015 1 commit
    • Junio C Hamano's avatar
      write_file_v(): do not leave incomplete line at the end · e7ffa38c
      Junio C Hamano authored
      All existing callers to this function use it to produce a text file
      or an empty file, and a new callsite that mimick them must end their
      payload with a LF.  If they forget to do so, the resulting file will
      end with an incomplete line.
      
      Teach write_file_v() to complete the incomplete line, if exists, so
      that the callers do not have to.
      
      With this, the caller-side fix in builtin/am.c becomes unnecessary.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      e7ffa38c
  22. 24 Aug, 2015 1 commit
    • Junio C Hamano's avatar
      write_file(): drop "fatal" parameter · 12d6ce1d
      Junio C Hamano authored
      All callers except three passed 1 for the "fatal" parameter to ask
      this function to die upon error, but to a casual reader of the code,
      it was not all obvious what that 1 meant.  Instead, split the
      function into two based on a common write_file_v() that takes the
      flag, introduce write_file_gently() as a new way to attempt creating
      a file without dying on error, and make three callers to call it.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      12d6ce1d
  23. 05 Aug, 2015 2 commits
  24. 05 Jun, 2015 1 commit
  25. 12 Feb, 2015 1 commit
  26. 01 Dec, 2014 1 commit
  27. 15 Oct, 2014 2 commits
  28. 28 Aug, 2014 1 commit
    • Steffen Prohaska's avatar
      memory_limit: use git_env_ulong() to parse GIT_ALLOC_LIMIT · 9927d962
      Steffen Prohaska authored
      GIT_ALLOC_LIMIT limits xmalloc()'s size, which is of type size_t.
      Better use git_env_ulong() to parse the environment variable, so
      that the postfixes 'k', 'm', and 'g' can be used; and use size_t to
      store the limit for consistency.  The change to size_t has no direct
      practical impact, because the environment variable is only meant to
      be used for our own tests, and we use it to test small sizes.
      
      The cast of size in the call to die() is changed to uintmax_t to
      match the format string PRIuMAX.
      Signed-off-by: default avatarSteffen Prohaska <prohaska@zib.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      9927d962
  29. 26 Aug, 2014 1 commit
  30. 18 Aug, 2014 1 commit
  31. 10 Apr, 2014 2 commits
    • Yiannis Marangos's avatar
      read-cache.c: verify index file before we opportunistically update it · 426ddeea
      Yiannis Marangos authored
      Before we proceed to opportunistically update the index (often done
      by an otherwise read-only operation like "git status" and "git diff"
      that internally refreshes the index), we must verify that the
      current index file is the same as the one that we read earlier
      before we took the lock on it, in order to avoid a possible race.
      
      In the example below git-status does "opportunistic update" and
      git-rebase updates the index, but the race can happen in general.
      
        1. process A calls git-rebase (or does anything that uses the index)
      
        2. process A applies 1st commit
      
        3. process B calls git-status (or does anything that updates the index)
      
        4. process B reads index
      
        5. process A applies 2nd commit
      
        6. process B takes the lock, then overwrites process A's changes.
      
        7. process A applies 3rd commit
      
      As an end result the 3rd commit will have a revert of the 2nd commit.
      When process B takes the lock, it needs to make sure that the index
      hasn't changed since step 4.
      Signed-off-by: default avatarYiannis Marangos <yiannis.marangos@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      426ddeea
    • Yiannis Marangos's avatar
      wrapper.c: add xpread() similar to xread() · 9aa91af0
      Yiannis Marangos authored
      It is a common mistake to call read(2)/pread(2) and forget to
      anticipate that they may return error with EAGAIN/EINTR when the
      system call is interrupted.
      
      We have xread() helper to relieve callers of read(2) from having to
      worry about it; add xpread() helper to do the same for pread(2).
      
      Update the caller in the builtin/index-pack.c and the mmap emulation
      in compat/.
      Signed-off-by: default avatarYiannis Marangos <yiannis.marangos@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      9aa91af0