- 02 Jan, 2019 1 commit
-
-
Pranit Bauva authored
is_empty_file() can help to refactor a lot of code. This will be very helpful in porting "git bisect" to C. Suggested-by:
Torsten Bögershausen <tboegi@web.de> Mentored-by:
Lars Schneider <larsxschneider@gmail.com> Mentored-by:
Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by:
Junio C Hamano <gitster@pobox.com>
-
- 06 May, 2018 1 commit
-
-
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 <johannes.schindelin@gmx.de> Signed-off-by:
-
- 22 Feb, 2018 1 commit
-
-
Brandon Williams authored
Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by:
Brandon Williams <bmwill@google.com> Signed-off-by:
-
- 06 Nov, 2017 1 commit
-
-
Simon Ruderich authored
All other error messages in the file use quotes around the file name. This change removes two translations as "could not write to '%s'" and "could not close '%s'" are already translated and these two are the only occurrences without quotes. Signed-off-by:
Simon Ruderich <simon@ruderich.org> [jc: adjusted tests I noticed were broken by the change] Signed-off-by:
-
- 14 Sep, 2017 1 commit
-
-
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:
Jeff King <peff@peff.net> Reviewed-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
-
- 15 Jun, 2017 1 commit
-
-
Brandon Williams authored
Stop including config.h by default in cache.h. Instead only include config.h in those files which require use of the config system. Signed-off-by:
-
- 30 May, 2017 1 commit
-
-
Junio C Hamano authored
Using the is_missing_file_error() helper introduced in the previous step, update all hits from $ git grep -e ENOENT --and -e ENOTDIR There are codepaths that only check ENOENT, and it is possible that some of them should be checking both. Updating them is kept out of this step deliberately, as we do not want to change behaviour in this step. Signed-off-by:
-
- 26 May, 2017 3 commits
-
-
Duy Nguyen authored
After the last patch, this function is not used outside anymore. Keep it static. Noticed-by:
Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by:
-
Duy Nguyen authored
When fopen() returns NULL, it could be because the given path does not exist, but it could also be some other errors and the caller has to check. Add a wrapper so we don't have to repeat the same error check everywhere. Signed-off-by:
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by:
-
Duy Nguyen authored
In many places, Git warns about an inaccessible file after a fopen() failed. To discern these cases from other cases where we want to warn about inaccessible files, introduce a new helper specifically to test whether fopen() failed because the current user lacks the permission to open file in question. Signed-off-by:
-
- 19 Apr, 2017 1 commit
-
-
David Turner (TS) authored
If the full hostname doesn't fit in the buffer supplied to gethostname, POSIX does not specify whether the buffer will be null-terminated, so to be safe, we should do it ourselves. Introduce new function, xgethostname, which ensures that there is always a \0 at the end of the buffer. Signed-off-by:
David Turner <dturner@twosigma.com> Signed-off-by:
-
- 28 Feb, 2017 2 commits
-
-
Ramsay Jones authored
The last call to the mkstemps() function was removed in commit 65948832 ("wrapper.c: delete dead function git_mkstemps()", 22-04-2016). In order to support platforms without mkstemps(), this functionality was provided, along with a Makefile build variable (NO_MKSTEMPS), by the gitmkstemps() function. Remove the dead code, along with the defunct build machinery. Signed-off-by:
-
Ramsay Jones authored
The last caller of git_mkstemp() was removed in commit 6fec0a89 ("verify_signed_buffer: use tempfile object", 16-06-2016). Since the introduction of the 'tempfile' APIs, along with git_mkstemp_mode, it is unlikely that new callers will materialize. Remove the dead code. Signed-off-by:
-
- 11 Jul, 2016 1 commit
-
-
Eric Wong authored
At least for me, this improves the readability of xread and xwrite; hopefully allowing missing "continue" statements to be spotted more easily. Signed-off-by:
Eric Wong <e@80x24.org> Signed-off-by:
-
- 08 Jul, 2016 3 commits
-
-
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: -
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:
-
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:
-
- 27 Jun, 2016 2 commits
-
-
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:
-
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:
-
- 09 May, 2016 1 commit
-
-
Duy Nguyen authored
Signed-off-by:
-
- 22 Apr, 2016 1 commit
-
-
Duy Nguyen authored
Its last call site was replaced by mks_tempfile_ts() in 284098f1 (diff: use tempfile module - 2015-08-12) and there's a good chance mks_tempfile_ts will continue to successfully handle this job. Delete it. Signed-off-by:
-
- 22 Feb, 2016 1 commit
-
-
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:
-
- 07 Jan, 2016 1 commit
-
-
Johannes Schindelin authored
It was pointed out by Yaroslav Halchenko that the file containing the commit message is writable only by the owner, which means that we have to rewrite it from scratch in a shared repository. Signed-off-by:
-
- 16 Dec, 2015 1 commit
-
-
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 <sbeller@google.com> Acked-by:
Johannes Sixt <j6t@kdbg.org> Signed-off-by:
-
- 10 Dec, 2015 1 commit
-
-
Jeff King authored
This function is defined in wrapper.c, but nobody besides ident.c uses it. And nobody is likely to in the future, either, as anything that cares about the user's name should be going through the ident code. Moving it here is a cleanup of the global namespace, but it will also enable further cleanups inside ident.c. Signed-off-by:
-
- 25 Sep, 2015 1 commit
-
-
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:
-
- 25 Aug, 2015 1 commit
-
-
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:
-
- 24 Aug, 2015 1 commit
-
-
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:
-
- 05 Aug, 2015 2 commits
-
-
Paul Tan authored
A common usage pattern of fopen() is to check if it succeeded, and die() if it failed: FILE *fp = fopen(path, "w"); if (!fp) die_errno(_("could not open '%s' for writing"), path); Implement a wrapper function xfopen() for the above, so that we can save a few lines of code and make the die() messages consistent. Helped-by:Paul Tan <pyokagan@gmail.com> Signed-off-by:
-
Paul Tan authored
A common usage pattern of open() is to check if it was successful, and die() if it was not: int fd = open(path, O_WRONLY | O_CREAT, 0777); if (fd < 0) die_errno(_("Could not open '%s' for writing."), path); Implement a wrapper function xopen() that does the above so that we can save a few lines of code, and make the die() messages consistent. Helped-by:
-
- 05 Jun, 2015 1 commit
-
-
Johannes Sixt authored
We want to use the new function elsewhere in a moment. Signed-off-by:
Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by:
-
- 12 Feb, 2015 1 commit
-
-
Junio C Hamano authored
Since 0b6806b9 (xread, xwrite: limit size of IO to 8MB, 2013-08-20), we chomp our calls to read(2) and write(2) into chunks of MAX_IO_SIZE bytes (8 MiB), because a large IO results in a bad latency when the program needs to be killed. This also brought our IO below SSIZE_MAX, which is a limit POSIX allows read(2) and write(2) to fail when the IO size exceeds it, for OS X, where a problem was originally reported. However, there are other systems that define SSIZE_MAX smaller than our default, and feeding 8 MiB to underlying read(2)/write(2) would fail. Make sure we clip our calls to the lower limit as well. Reported-by:
Joachim Schmitz <jojo@schmitz-digital.de> Helped-by:
Eric Sunshine <sunshine@sunshineco.com> Signed-off-by:
-
- 01 Dec, 2014 1 commit
-
-
Duy Nguyen authored
Signed-off-by:
-
- 15 Oct, 2014 2 commits
-
-
Ronnie Sahlberg authored
This behaves like unlink_or_warn except that on failure it writes the message to its 'err' argument, which the caller can display in an appropriate way or ignore. Signed-off-by:
Ronnie Sahlberg <sahlberg@google.com> Reviewed-by:
-
Ronnie Sahlberg authored
Simplify the function warn_if_unremovable slightly. Additionally, change behaviour slightly. If we failed to remove the object because the object does not exist, we can still return success back to the caller since none of the callers depend on "fail if the file did not exist". Signed-off-by:
-
- 28 Aug, 2014 1 commit
-
-
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:
Steffen Prohaska <prohaska@zib.de> Signed-off-by:
-
- 26 Aug, 2014 1 commit
-
-
René Scharfe authored
Add the helper function xgetcwd(), which returns the current directory or dies. The returned string has to be free()d after use. Helped-by:
Rene Scharfe <l.s.r@web.de> Signed-off-by:
-
- 18 Aug, 2014 1 commit
-
-
Duy Nguyen authored
Signed-off-by:
-
- 10 Apr, 2014 2 commits
-
-
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:
Yiannis Marangos <yiannis.marangos@gmail.com> Signed-off-by:
-
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:
-
