- 02 7月, 2016 1 次提交
-
-
由 Jeff King 提交于
There are certain startup tasks that we expect every git process to do. In some cases this is just to improve the quality of the program (e.g., setting up gettext()). In others it is a requirement for using certain functions in libgit.a (e.g., system_path() expects that you have called git_extract_argv0_path()). Most commands are builtins and are covered by the git.c version of main(). However, there are still a few external commands that use their own main(). Each of these has to remember to include the correct startup sequence, and we are not always consistent. Rather than just fix the inconsistencies, let's make this harder to get wrong by providing a common main() that can run this standard startup. We basically have two options to do this: - the compat/mingw.h file already does something like this by adding a #define that replaces the definition of main with a wrapper that calls mingw_startup(). The upside is that the code in each program doesn't need to be changed at all; it's rewritten on the fly by the preprocessor. The downside is that it may make debugging of the startup sequence a bit more confusing, as the preprocessor is quietly inserting new code. - the builtin functions are all of the form cmd_foo(), and git.c's main() calls them. This is much more explicit, which may make things more obvious to somebody reading the code. It's also more flexible (because of course we have to figure out _which_ cmd_foo() to call). The downside is that each of the builtins must define cmd_foo(), instead of just main(). This patch chooses the latter option, preferring the more explicit approach, even though it is more invasive. We introduce a new file common-main.c, with the "real" main. It expects to call cmd_main() from whatever other objects it is linked against. We link common-main.o against anything that links against libgit.a, since we know that such programs will need to do this setup. Note that common-main.o can't actually go inside libgit.a, as the linker would not pick up its main() function automatically (it has no callers). The rest of the patch is just adjusting all of the various external programs (mostly in t/helper) to use cmd_main(). I've provided a global declaration for cmd_main(), which means that all of the programs also need to match its signature. In particular, many functions need to switch to "const char **" instead of "char **" for argv. This effect ripples out to a few other variables and functions, as well. This makes the patch even more invasive, but the end result is much better. We should be treating argv strings as const anyway, and now all programs conform to the same signature (which also matches the way builtins are defined). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 5月, 2016 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Similar to die_errno(), these functions will append strerror() automatically. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 4月, 2016 1 次提交
-
-
由 Kazuki Yamaguchi 提交于
We don't need it, as we no longer use HMAC_CTX_cleanup() directly. Signed-off-by: NKazuki Yamaguchi <k@rhe.jp> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 3月, 2016 1 次提交
-
-
由 Eric Sunshine 提交于
Although changes by 5b442c4f (tree-diff: catch integer overflow in combine_diff_path allocation, 2016-02-19) are perfectly valid, they unfortunately trigger an internal compiler error in gcc 4.2.x: combine-diff.c: In function 'diff_tree_combined': combine-diff.c:1391: internal compiler error: Segmentation fault: 11 Experimentation reveals that changing st_add4()'s argument evaluation order is sufficient to sidestep this problem. Although st_add3() does not trigger the compiler bug, for style consistency, change its argument evaluation order to match. Signed-off-by: NEric Sunshine <sunshine@sunshineco.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 3月, 2016 1 次提交
-
-
由 Jeff King 提交于
Performing computations on size_t variables that we feed to xmalloc and friends can be dangerous, as an integer overflow can cause us to allocate a much smaller chunk than we realized. We already have unsigned_add_overflows(), but let's add unsigned_mult_overflows() to that. Furthermore, rather than have each site manually check and die on overflow, we can provide some helpers that will: - promote the arguments to size_t, so that we know we are doing our computation in the same size of integer that will ultimately be fed to xmalloc - check and die on overflow - return the result so that computations can be done in the parameter list of xmalloc. These functions are a lot uglier to use than normal arithmetic operators (you have to do "st_add(foo, bar)" instead of "foo + bar"). To at least limit the damage, we also provide multi-valued versions. So rather than: st_add(st_add(a, b), st_add(c, d)); you can write: st_add4(a, b, c, d); This isn't nearly as elegant as a varargs function, but it's a lot harder to get it wrong. You don't have to remember to add a sentinel value at the end, and the compiler will complain if you get the number of arguments wrong. This patch adds only the numbered variants required to convert the current code base; we can easily add more later if needed. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 2月, 2016 3 次提交
-
-
由 Jeff King 提交于
There are no callers of this left, as the last one was dropped in the previous patch. And there are not likely to be new ones, as the function has been around since 2010 without gaining any new callers. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
Allocating a struct with a flex array is pretty simple in practice: you over-allocate the struct, then copy some data into the over-allocation. But it can be a slight pain to make sure you're allocating and copying the right amounts. This patch adds a few helpers to turn simple cases of flex-array struct allocation into a one-liner that properly checks for overflow. See the embedded documentation for details. Ideally we could provide a more flexible version that could handle multiple strings, like: FLEX_ALLOC_FMT(ref, name, "%s%s", prefix, name); But we have to implement this as a macro (because of the offset calculation of the flex member), which means we would need all compilers to support variadic macros. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 2月, 2016 1 次提交
-
-
由 Alexander Kuleshov 提交于
The handle_builtin() starts from stripping of command extension if STRIP_EXTENSION is enabled. Actually STRIP_EXTENSION does not used anywhere else. This patch introduces strip_extension() helper to strip STRIP_EXTENSION extension from argv[0] with the strip_suffix() instead of manually stripping. Signed-off-by: NAlexander Kuleshov <kuleshovmail@gmail.com> Helped-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 2月, 2016 1 次提交
-
-
由 Jeff King 提交于
Performing computations on size_t variables that we feed to xmalloc and friends can be dangerous, as an integer overflow can cause us to allocate a much smaller chunk than we realized. We already have unsigned_add_overflows(), but let's add unsigned_mult_overflows() to that. Furthermore, rather than have each site manually check and die on overflow, we can provide some helpers that will: - promote the arguments to size_t, so that we know we are doing our computation in the same size of integer that will ultimately be fed to xmalloc - check and die on overflow - return the result so that computations can be done in the parameter list of xmalloc. These functions are a lot uglier to use than normal arithmetic operators (you have to do "st_add(foo, bar)" instead of "foo + bar"). To at least limit the damage, we also provide multi-valued versions. So rather than: st_add(st_add(a, b), st_add(c, d)); you can write: st_add4(a, b, c, d); This isn't nearly as elegant as a varargs function, but it's a lot harder to get it wrong. You don't have to remember to add a sentinel value at the end, and the compiler will complain if you get the number of arguments wrong. This patch adds only the numbered variants required to convert the current code base; we can easily add more later if needed. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 1月, 2016 2 次提交
-
-
由 Johannes Schindelin 提交于
When there is no `libgen.h` to our disposal, we miss the `dirname()` function. Earlier we added basename() compatibility function for the same reason at e1c06886 (compat: add a basename() compatibility function, 2009-05-31). So far, we only had one user of that function: credential-cache--daemon (which was only compiled when Unix sockets are available, anyway). But now we also have `builtin/am.c` as user, so we need it. Since `dirname()` is a sibling of `basename()`, we simply put our very own `gitdirname()` implementation next to `gitbasename()` and use it if `NO_LIBGEN_H` has been set. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
Junio noticed that there is an implicit assumption in pretty much all the code calling has_dos_drive_prefix(): it forces all of its callsites to hardcode the knowledge that the DOS drive prefix is always two bytes long. While this assumption is pretty safe, we can still make the code more readable and less error-prone by introducing a function that skips the DOS drive prefix safely. While at it, we change the has_dos_drive_prefix() return value: it now returns the number of bytes to be skipped if there is a DOS drive prefix. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 1月, 2016 1 次提交
-
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 12月, 2015 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 10月, 2015 2 次提交
-
-
由 Waldek Maleska 提交于
This fix is probably purely cosmetic because PRIuMAX is likely identical to SCNuMAX. Nevertheless, when using a function of the scanf() family, the correct interpolation to use is the latter, not the former. Signed-off-by: NWaldek Maleska <w.maleska@gmail.com> Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
We cannot rely on long integers to have more than 32 bits. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 10月, 2015 1 次提交
-
-
由 Jeff King 提交于
When we are initializing a .git directory, we may call probe_utf8_pathname_composition to detect utf8 mangling. We pass in a path buffer for it to use, and it blindly strcpy()s into it, not knowing whether the buffer is large enough to hold the result or not. In practice this isn't a big deal, because the buffer we pass in already contains "$GIT_DIR/config", and we append only a few extra bytes to it. But we can easily do the right thing just by calling git_path_buf ourselves. Technically this results in a different pathname (before we appended our utf8 characters to the "config" path, and now they get their own files in $GIT_DIR), but that should not matter for our purposes. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 9月, 2015 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 9月, 2015 1 次提交
-
-
由 Matthieu Moy 提交于
strtoul_ui uses strtoul to get a long unsigned, then checks that casting to unsigned does not lose information and return the casted value. On 64 bits architecture, checking that the cast does not change the value catches most errors, but when sizeof(int) == sizeof(long) (e.g. i386), the check does nothing. Unfortunately, strtoul silently accepts negative values, and as a result strtoul_ui("-1", ...) raised no error. This patch catches negative values before it's too late, i.e. before calling strtoul. Reported-by: NMax Kirillov <max@max630.net> Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 8月, 2015 1 次提交
-
-
由 Jeff King 提交于
The vreportf function always goes to stderr, but run-command wants child errors to go to the parent's original stderr. To solve this, commit a5487ddf duplicates the stderr fd and installs die and error handlers to direct the output appropriately (which later turned into the vwritef function). This has two downsides, though: - we make multiple calls to write(), which contradicts the "write at once" logic from d048a96e (print warning/error/fatal messages in one shot, 2007-11-09). - the custom handlers basically duplicate the normal handlers. They're only a few lines of code, but we should not have to repeat the magic "exit(128)", for example. We can solve the first by using fdopen() on the duplicated descriptor. We can't pass this to vreportf, but we could introduce a new vreportf_to to handle it. However, to fix the second problem, we instead introduce a new "set_error_handle" function, which lets the normal vreportf calls output to a handle besides stderr. Thus we can get rid of our custom handlers entirely, and just ask the regular handlers to output to our new descriptor. And as vwritef has no more callers, it can just go away. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 8月, 2015 2 次提交
-
-
由 Paul Tan 提交于
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: NJeff King <peff@peff.net> Helped-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Helped-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NPaul Tan <pyokagan@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Paul Tan 提交于
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: NTorsten Bögershausen <tboegi@web.de> Helped-by: NJeff King <peff@peff.net> Helped-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Helped-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NPaul Tan <pyokagan@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 6月, 2015 1 次提交
-
-
由 Charles Bailey 提交于
The improved ARRAY_SIZE macro uses BARF_UNLESS_AN_ARRAY which expands to a valid check for recent gcc versions and to 0 for older gcc versions but is not defined on non-gcc builds. Non-gcc builds need this macro to expand to 0 as well. The current outer test (defined(__GNUC__) && (__GNUC__ >= 3)) is a strictly weaker condition than the inner test (GIT_GNUC_PREREQ(3, 1)) so we can omit the outer test and cause the BARF_UNLESS_AN_ARRAY macro to be defined correctly on non-gcc builds as well as gcc builds with older versions. Signed-off-by: NCharles Bailey <cbailey32@bloomberg.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 5月, 2015 1 次提交
-
-
由 Jeff King 提交于
The config-writing code uses xmmap to map the existing config file, which will die if the map fails. This has two downsides: 1. The error message is not very helpful, as it lacks any context about the file we are mapping: $ mkdir foo $ git config --file=foo some.key value fatal: Out of memory? mmap failed: No such device 2. We normally do not die in this code path; instead, we'd rather report the error and return an appropriate exit status (which is part of the public interface documented in git-config.1). This patch introduces a "gentle" form of xmmap which lets us produce our own error message. We do not want to use mmap directly, because we would like to use the other compatibility elements of xmmap (e.g., handling 0-length maps portably). The end result is: $ git.compile config --file=foo some.key value error: unable to mmap 'foo': No such device $ echo $? 3 Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 5月, 2015 1 次提交
-
-
由 Elia Pinto 提交于
To get number of elements in an array git use the ARRAY_SIZE macro defined as: #define ARRAY_SIZE(x) (sizeof(x)/sizeof((x)[0])) The problem with it is a possibility of mistakenly passing to it a pointer instead an array. The ARRAY_SIZE macro as conventionally defined does not provide good type-safety and the open-coded approach is more fragile, more verbose and provides no improvement in type-safety. Use instead a different but compatible ARRAY_SIZE() macro, which will also break compile if you try to use it on a pointer. This implemention revert to the original code if the compiler doesn't know the typeof and __builtin_types_compatible_p GCC extensions. This can ensure our code is robust to changes, without needing a gratuitous macro or constant. A similar ARRAY_SIZE implementation also exists in the linux kernel. Credits to Rusty Russell and his ccan library. Signed-off-by: NElia Pinto <gitter.spiros@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 4月, 2015 1 次提交
-
-
由 Jeff King 提交于
POSIX.1-2001 specifies some functions for optimizing the locking out of tight getc() loops. Not all systems are POSIX, though, and even not all POSIX systems are required to implement these functions. We can check for the feature-test macro to see if they are available, and if not, provide a noop implementation. There's no Makefile knob here, because we should just detect this automatically. If there are very bizarre systems, we may need to add one, but it's not clear yet in which direction: 1. If a system defines _POSIX_THREAD_SAFE_FUNCTIONS but these functions are missing or broken, we would want a knob to manually turn them off. 2. If a system has these functions but does not define _POSIX_THREAD_SAFE_FUNCTIONS, we would want a knob to manually turn them on. We can add such a knob when we find a real-world system that matches this. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 3月, 2015 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
If the user enables untracked cache, then - move worktree to an unsupported filesystem - or simply upgrade OS - or move the whole (portable) disk from one machine to another - or access a shared fs from another machine there's no guarantee that untracked cache can still function properly. Record the worktree location and OS footprint in the cache. If it changes, err on the safe side and disable the cache. The user can 'update-index --untracked-cache' again to make sure all conditions are met. This adds a new requirement that setup_git_directory* must be called before read_cache() because we need worktree location by then, or the cache is dropped. This change does not cover all bases, you can fool it if you try hard. The point is to stop accidents. Helped-by: NEric Sunshine <sunshine@sunshineco.com> Helped-by: Nbrian m. carlson <sandals@crustytoothpaste.net> Helped-by: NTorsten Bögershausen <tboegi@web.de> Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 3月, 2015 2 次提交
-
-
由 Kyle J. McKay 提交于
On BSD-compatible systems some information such as the number of available CPUs may only be available via the sysctl function. Add support for a HAVE_BSD_SYSCTL option complete with autoconf support and include the sys/syctl.h header when the option is enabled to make the sysctl function available. Signed-off-by: NKyle J. McKay <mackyle@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Kyle J. McKay 提交于
If SHELL_PATH is not defined we use "/bin/sh". However, run-command.c is not the only file that needs to use the default value so move it into a common header. Signed-off-by: NKyle J. McKay <mackyle@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 3月, 2015 1 次提交
-
-
由 Ben Walton 提交于
Sun Studio on Solaris issues warnings about improper initialization values being used when defining tolower_trans_tbl[] in ctype.c. The array wants to store values with high-bit set and treat them as values between 128 to 255. Unlike the rest of the Git codebase where we explicitly specify 'unsigned char' for such variables and arrays, however, kwset code we borrowed from elsewhere uses 'char' for this and other variables. Fix the declarations to explicitly use 'unsigned char' where necessary to bring it in line with the rest of the Git. Signed-off-by: NBen Walton <bdwalton@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 2月, 2015 1 次提交
-
-
由 Ramsay Jones 提交于
Since commit 3a0a3a89 ("git-compat-util.h: don't define _XOPEN_SOURCE on cygwin", 23-11-2014) removed the definition of _XOPEN_SOURCE on cygwin, the code within a pre-processor conditional further down the file became redundant. Remove the redundant code. This effectively reverts commit 41b20017 ("Fix an "implicit function definition" warning", 03-03-2007). Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 2月, 2015 1 次提交
-
-
由 Kyle J. McKay 提交于
MAC_OS_X_VERSION_MIN_REQUIRED may be defined by the builder to a specific version in order to produce compatible binaries for a particular system. Blindly defining it to MAC_OS_X_VERSION_10_6 is bad. Additionally MAC_OS_X_VERSION_10_6 will not be defined on older systems and should AvailabilityMacros.h be included on such as system an error will result. However, using the explicit value of 1060 (which is what MAC_OS_X_VERSION_10_6 is defined to) does not solve the problem. The changes that introduced stepping on MAC_OS_X_VERSION_MIN were made in b195aa00 (git-compat-util: suppress unavoidable Apple-specific deprecation warnings) to avoid deprecation warnings. Instead of blindly setting MAC_OS_X_VERSION_MIN to 1060 change the definition of DEPRECATED_ATTRIBUTE to empty to avoid the warnings. This preserves any MAC_OS_X_VERSION_MIN_REQUIRED setting while avoiding the warnings as intended by b195aa00. Signed-off-by: NKyle J. McKay <mackyle@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 1月, 2015 1 次提交
-
-
由 Jeff King 提交于
It's a common idiom to duplicate a string if it is non-NULL, or pass a literal NULL through. This is already a one-liner in C, but you do have to repeat the name of the string twice. So if there's a function call, you must write: const char *x = some_fun(...); return x ? xstrdup(x) : NULL; instead of (with this patch) just: return xstrdup_or_null(some_fun(...)); Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 1月, 2015 1 次提交
-
-
由 Kyle J. McKay 提交于
The gettext N_ macro is used to mark strings for translation without actually translating them. At runtime the string is expected to be passed to the gettext API for translation. If two N_ macro invocations appear next to each other with only whitespace (or nothing at all) between them, the two separate strings will be marked for translation, but the preprocessor will then silently combine the strings into one and at runtime the string passed to gettext will not match the strings that were translated so no translation will actually occur. Avoid this by adding parentheses around the expansion of the N_ macro so that instead of ending up with two adjacent strings that are then combined by the preprocessor, two adjacent strings surrounded by parentheses result instead which causes a compile error so the mistake can be quickly found and corrected. However, since these string literals are typically assigned to static variables and not all compilers support parenthesized string literal assignments, allow this to be controlled by the Makefile with the default only enabled when the compiler is known to support the syntax. For now only __GNUC__ enables this by default which covers both gcc and clang which should result in early detection of any adjacent N_ macros. Although the necessary tests make the affected files a bit less elegant, the benefit of avoiding propagation of a translation- marking error to all the translation teams thus creating extra work for them when the error is eventually detected and fixed would seem to outweigh the minor inelegance the additional configuration tests introduce. Helped-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NKyle J. McKay <mackyle@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 1月, 2015 1 次提交
-
-
由 Reuben Hawkins 提交于
OpenSSL version 0.9.6b and before defined the function HMAC_cleanup. Newer versions define HMAC_CTX_cleanup. Check for HMAC_CTX_cleanup and fall back to HMAC_cleanup when the newer function is missing. Signed-off-by: NReuben Hawkins <reubenhwk@gmail.com> Reviewed-by: NEric Sunshine <sunshine@sunshineco.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 12月, 2014 1 次提交
-
-
由 Eric Sunshine 提交于
With the release of Mac OS X 10.7 in July 2011, Apple deprecated all openssl.h functionality due to OpenSSL ABI (application binary interface) instability, resulting in an explosion of compilation warnings about deprecated SSL, SHA1, and X509 functions (among others). 61067954 (cache.h: eliminate SHA-1 deprecation warnings on Mac OS X; 2013-05-19) and be4c828b (imap-send: eliminate HMAC deprecation warnings on Mac OS X; 2013-05-19) attempted to ameliorate the situation by taking advantage of drop-in replacement functionality provided by Apple's (ABI-stable) CommonCrypto facility, however CommonCrypto supplies only a subset of deprecated OpenSSL functionality, thus a host of warnings remain. Despite this shortcoming, it was hoped that Apple would ultimately provide CommonCrypto replacements for all deprecated OpenSSL functionality, and that the effort started by 61067954 and be4c828b would be continued and eventually eliminate all deprecation warnings. However, now 3.5 years later, and with Mac OS X at 10.10, the hoped-for CommonCrypto replacements have not yet materialized, nor is there any indication that they will be forthcoming. These Apple-specific warnings are pure noise: they don't tell us anything useful and we have no control over them, nor is Apple likely to provide replacements any time soon. Such noise may obscure other legitimate warnings, therefore silence them. Signed-off-by: NEric Sunshine <sunshine@sunshineco.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 12月, 2014 1 次提交
-
-
由 David Michael 提交于
This adds simple wrapper functions around calls to stat(), fstat(), and lstat() that translate the operating system's native file type bits to those used by most operating systems. It also rewrites the S_IF* macros to the common values, so all file type processing is performed using the translated modes. This makes projects portable across operating systems that use different file type definitions. Only the file type bits may be affected by these compatibility functions; the file permission bits are assumed to be 07777 and are passed through unchanged. Signed-off-by: NDavid Michael <fedora.dm0@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 11月, 2014 1 次提交
-
-
由 Ramsay Jones 提交于
A recent update to the gcc compiler (v4.8.3-5 x86_64) on 64-bit cygwin leads to several new warnings about the implicit declaration of the memmem(), strlcpy() and strcasestr() functions. For example: CC archive.o archive.c: In function 'format_subst': archive.c:44:3: warning: implicit declaration of function 'memmem' \ [-Wimplicit-function-declaration] b = memmem(src, len, "$Format:", 8); ^ archive.c:44:5: warning: assignment makes pointer from integer \ without a cast [enabled by default] b = memmem(src, len, "$Format:", 8); ^ This is because <string.h> on Cygwin used to always declare the above functions, but a recent version of it no longer make them visible when _XOPEN_SOURCE is set (even if _GNU_SOURCE and _BSD_SOURCE is set). In order to suppress the warnings, don't define the _XOPEN_SOURCE macro on cygwin. Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 10月, 2014 1 次提交
-
-
由 David Michael 提交于
When the XL C compiler is run with an appropriate language level or suboption, it defines a feature test macro to indicate support for variadic macros by defining __C99_MACRO_WITH_VA_ARGS C preprocessor macro. This was tested on z/OS, but it should also work on AIX according to IBM documentation. Signed-off-by: NDavid Michael <fedora.dm0@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 10月, 2014 1 次提交
-
-
由 Etienne Buira 提交于
Wrap atexit()s calls on unthreaded builds to handle callback list internally. This is needed because on unthreaded builds, asyncs inherits parent's atexit() list, that gets run as soon as the async exit()s (and again at the end of async's parent process). That led to remove temporary files too early. Also remove a by-atexit-callback guard against this kind of issue in clone.c, as this patch makes it redundant. Fixes test 5537 (temporary shallow file vanished before unpack-objects could open it) BTW remove an unused variable in shallow.c. Helped-by: NDuy Nguyen <pclouds@gmail.com> Helped-by: NAndreas Schwab <schwab@linux-m68k.org> Helped-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NEtienne Buira <etienne.buira@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-