summaryrefslogtreecommitdiff
path: root/compat
AgeCommit message (Collapse)AuthorFilesLines
2019-07-11Merge branch 'js/mingw-use-utf8'Libravatar Junio C Hamano3-8/+16
Windows update. * js/mingw-use-utf8: mingw: fix possible buffer overrun when calling `GetUserNameW()` mingw: use Unicode functions explicitly mingw: get pw_name in UTF-8 format
2019-07-11Merge branch 'cb/windows-manifest'Libravatar Junio C Hamano1-0/+25
Windows update. * cb/windows-manifest: mingw: embed a manifest to trick UAC into Doing The Right Thing
2019-07-09Merge branch 'jh/msvc'Libravatar Junio C Hamano11-37/+481
Support to build with MSVC has been updated. * jh/msvc: msvc: ignore .dll and incremental compile output msvc: avoid debug assertion windows in Debug Mode msvc: do not pretend to support all signals msvc: add pragmas for common warnings msvc: add a compile-time flag to allow detailed heap debugging msvc: support building Git using MS Visual C++ msvc: update Makefile to allow for spaces in the compiler path msvc: fix detect_msys_tty() msvc: define ftello() msvc: do not re-declare the timespec struct msvc: mark a variable as non-const msvc: define O_ACCMODE msvc: include sigset_t definition msvc: fix dependencies of compat/msvc.c mingw: replace mingw_startup() hack obstack: fix compiler warning cache-tree/blame: avoid reusing the DEBUG constant t0001 (mingw): do not expect a specific order of stdout/stderr Mark .bat files as requiring CR/LF endings mingw: fix a typo in the msysGit-specific section
2019-07-08mingw: fix possible buffer overrun when calling `GetUserNameW()`Libravatar Johannes Schindelin1-1/+1
In 39a98e9b68b8 (mingw: get pw_name in UTF-8 format, 2019-06-27), this developer missed the fact that the `GetUserNameW()` function takes the number of characters as `len` parameter, not the number of bytes. Reported-by: Beat Bolli <dev+git@drbeat.li> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-27mingw: use Unicode functions explicitlyLibravatar Johannes Schindelin3-6/+8
Many Win32 API functions actually exist in two variants: one with the `A` suffix that takes ANSI parameters (`char *` or `const char *`) and one with the `W` suffix that takes Unicode parameters (`wchar_t *` or `const wchar_t *`). The ANSI variant assumes that the strings are encoded according to whatever is the current locale. This is not what Git wants to use on Windows: we assume that `char *` variables point to strings encoded in UTF-8. There is a pseudo UTF-8 locale on Windows, but it does not work as one might expect. In addition, if we overrode the user's locale, that would modify the behavior of programs spawned by Git (such as editors, difftools, etc), therefore we cannot use that pseudo locale. Further, it is actually highly encouraged to use the Unicode versions instead of the ANSI versions, so let's do precisely that. Note: when calling the Win32 API functions _without_ any suffix, it depends whether the `UNICODE` constant is defined before the relevant headers are #include'd. Without that constant, the ANSI variants are used. Let's be explicit and avoid that ambiguity. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-27mingw: get pw_name in UTF-8 formatLibravatar Johannes Schindelin1-2/+8
Previously, we would have obtained the user name encoded in whatever the current code page is. Note: the "user name" here does not denote the full name but instead the short logon name. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-27mingw: embed a manifest to trick UAC into Doing The Right ThingLibravatar Cesar Eduardo Barros1-0/+25
On Windows >= Vista, not having an application manifest with a requestedExecutionLevel can cause several kinds of confusing behavior. The first and more obvious behavior is "Installer Detection" of the "User Account Control" (also known as "UAC") feature, where Windows sometimes decides (by looking at things like the file name and even sequences of bytes within the executable) that an executable is an installer and should run elevated (causing the well-known popup dialog to appear). In Git's context, subcommands such as "git patch-id" or "git update-index" fall prey to this behavior. The second and more confusing behavior is "File Virtualization". It means that when files are written without having write permission, it does not fail (as expected), but they are instead redirected to somewhere else. When the files are read, the original contents are returned, though, not the ones that were just written somewhere else. Even more confusing, not all write accesses are redirected; Trying to write to write-protected .exe files, for example, will fail instead of redirecting. In addition to being unwanted behavior, File Virtualization causes dramatic slowdowns in Git (see for instance http://code.google.com/p/msysgit/issues/detail?id=320). A third unwanted behavior of Windows >= Vista is that it lies about the Windows version when calling `GetWindowsVersionEx()`. There are two ways to prevent these unwanted behaviors: Either you embed an application manifest (which really is an XML document conforming to a specific schema) within all your executables, or you add an external manifest (a file with the same name followed by `.manifest`) to all your executables. Since Git's builtins are hardlinked (or copied), it is simpler and more robust to embed a manifest. Recent enough MSVC compilers already embed a working internal manifest, and building with mingw-w64 (which is the case in Git for Windows' SDK) does it, too, but for MinGW you have to do so by hand. In any case, it is better to be explicit about this manifest, that way changes in the compiler toolchain won't surprise us (as mingw-w64 once did when it broke `GetWindowsVersionEx()` by mistake). References: - New UAC Technologies for Windows Vista http://msdn.microsoft.com/en-us/library/bb756960.aspx - Create and Embed an Application Manifest (UAC) http://msdn.microsoft.com/en-us/library/bb756929.aspx Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25msvc: avoid debug assertion windows in Debug ModeLibravatar Johannes Schindelin1-0/+4
For regular debugging, it is pretty helpful when a debug assertion in a running application triggers a window that offers to start the debugger. However, when running the test suite, it is not so helpful, in particular when the debug assertions are then suppressed anyway because we disable the invalid parameter checking (via invalidcontinue.obj, see the comment in config.mak.uname about that object for more information). So let's simply disable that window in Debug Mode (it is already disabled in Release Mode). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25msvc: do not pretend to support all signalsLibravatar Jeff Hostetler1-0/+25
This special-cases various signals that are not supported on Windows, such as SIGPIPE. These cause the UCRT to throw asserts (at least in debug mode). Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25msvc: add pragmas for common warningsLibravatar Philip Oakley1-0/+4
MSVC can be overzealous about some warnings. Disable them. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25msvc: add a compile-time flag to allow detailed heap debuggingLibravatar Jeff Hostetler1-0/+6
MS Visual C comes with a few neat features we can use to analyze the heap consumption (i.e. leaks, max memory, etc). With this patch, we introduce support via the build-time flag `USE_MSVC_CRTDBG`. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25msvc: support building Git using MS Visual C++Libravatar Jeff Hostetler7-5/+371
With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20msvc: fix detect_msys_tty()Libravatar Jeff Hostetler1-0/+13
The ntstatus.h header is only available in MINGW. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20msvc: define ftello()Libravatar Jeff Hostetler1-0/+2
It is just called differently in MSVC's headers. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20msvc: do not re-declare the timespec structLibravatar Jeff Hostetler1-0/+2
VS2015's headers already declare that struct. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20msvc: mark a variable as non-constLibravatar Jeff Hostetler1-1/+4
VS2015 complains when using a const pointer in memcpy()/free(). Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20msvc: define O_ACCMODELibravatar Philip Oakley1-0/+2
This constant is not defined in MSVC's headers. In UCRT's fcntl.h, _O_RDONLY, _O_WRONLY and _O_RDWR are defined as 0, 1 and 2, respectively. Yes, that means that UCRT breaks with the tradition that O_RDWR == O_RDONLY | O_WRONLY. It is a perfectly legal way to define those constants, though, therefore we need to take care of defining O_ACCMODE accordingly. This is particularly important in order to keep our "open() can set errno to EISDIR" emulation working: it tests that (flags & O_ACCMODE) is not identical to O_RDONLY before going on to test specifically whether the file for which open() reported EACCES is, in fact, a directory. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20msvc: include sigset_t definitionLibravatar Philip Oakley1-0/+2
On MSVC (VS2008) sigset_t is not defined. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20mingw: replace mingw_startup() hackLibravatar Johannes Schindelin2-30/+45
Git for Windows has special code to retrieve the command-line parameters (and even the environment) in UTF-16 encoding, so that they can be converted to UTF-8. This is necessary because Git for Windows wants to use UTF-8 encoded strings throughout its code, and the main() function does not get the parameters in that encoding. To do that, we used the __wgetmainargs() function, which is not even a Win32 API function, but provided by the MINGW "runtime" instead. Obviously, this method would not work with any compiler other than GCC, and in preparation for compiling with Visual C++, we would like to avoid precisely that. Lucky us, there is a much more elegant way: we can simply implement the UTF-16 variant of `main()`: `wmain()`. To make that work, we need to link with -municode. The command-line parameters are passed to `wmain()` encoded in UTF-16, as desired, and this method also works with GCC, and also with Visual C++ after adjusting the MSVC linker flags to force it to use `wmain()`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20obstack: fix compiler warningLibravatar Johannes Schindelin1-1/+1
MS Visual C suggests that the construct condition ? (int) i : (ptrdiff_t) d is incorrect. Let's fix this by casting to ptrdiff_t also for the positive arm of the conditional. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-13winansi: simplify loading the GetCurrentConsoleFontEx() functionLibravatar Johannes Schindelin1-9/+5
We introduced helper macros to simplify loading functions dynamically. Might just as well use them. This also side-steps a compiler warning when building with GCC v8.x: it would complain about casting between incompatible function pointers. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-13poll (mingw): allow compiling with GCC 8 and DEVELOPER=1Libravatar Johannes Schindelin1-1/+1
The return type of the `GetProcAddress()` function is `FARPROC` which evaluates to `long long int (*)()`, i.e. it cannot be cast to the correct function signature by GCC 8. To work around that, we first cast to `void *` and go on with our merry lives. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-19Merge branch 'tt/no-ipv6-fallback-for-winxp'Libravatar Junio C Hamano2-183/+3
Code cleanup. * tt/no-ipv6-fallback-for-winxp: mingw: remove obsolete IPv6-related code
2019-05-13Merge branch 'cc/access-on-aix-workaround'Libravatar Junio C Hamano2-1/+32
Workaround for standard-compliant but less-than-useful behaviour of access(2) for the root user. * cc/access-on-aix-workaround: git-compat-util: work around for access(X_OK) under root
2019-05-07mingw: remove obsolete IPv6-related codeLibravatar Tanushree Tumane2-183/+3
To support IPv6, Git provided fall back functions for Windows versions that did not support IPv6. However, as Git dropped support for Windows XP and prior, those functions are not needed anymore. Remove those fallbacks by reverting fe3b2b7b827c (Enable support for IPv6 on MinGW, 2009-11-24) and using the functions directly (without 'ipv6_' prefix). Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-25git-compat-util: work around for access(X_OK) under rootLibravatar Clément Chigot2-1/+32
On AIX, access(X_OK) may succeed when run as root even if the execution isn't possible. This behavior is allowed by POSIX which says: ... for a process with appropriate privileges, an implementation may indicate success for X_OK even if execute permission is not granted to any user. It can lead hook programs to have their execution refused: git commit -m content fatal: cannot exec '.git/hooks/pre-commit': Permission denied Add NEED_ACCESS_ROOT_HANDLER in order to use an access helper function. It checks with stat if any executable flags is set when the current user is root. Signed-off-by: Clément Chigot <clement.chigot@atos.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-16trace2: report peak memory usage of the processLibravatar Jeff Hostetler1-3/+47
Teach Windows version of git to report peak memory usage during exit() processing. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-16trace2: refactor setting process starting timeLibravatar Jeff Hostetler1-0/+2
Create trace2_initialize_clock() and call from main() to capture process start time in isolation and before other sub-systems are ready. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-11Merge branch 'jk/guard-bswap-header'Libravatar Junio C Hamano1-0/+5
The include file compat/bswap.h has been updated so that it is safe to (accidentally) include it more than once. * jk/guard-bswap-header: compat/bswap: add include header guards
2019-03-07compat/bswap: add include header guardsLibravatar Jeff King1-0/+5
Our compat/bswap.h lacks the usual preprocessor guards against multiple inclusion. This usually isn't an issue since it only gets included from git-compat-util.h, which has its own guards. But it would produce redeclaration errors if any file included it separately. Our hdr-check target would complain about this, except that it currently skips items in compat/ entirely. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22trace2: collect Windows-specific process informationLibravatar Jeff Hostetler1-0/+147
Add platform-specific interface to log information about the current process. On Windows, this interface is used to indicate whether the git process is running under a debugger and list names of the process ancestors. Information for other platforms is left for a future effort. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22trace2: create new combined trace facilityLibravatar Jeff Hostetler2-3/+11
Create a new unified tracing facility for git. The eventual intent is to replace the current trace_printf* and trace_performance* routines with a unified set of git_trace2* routines. In addition to the usual printf-style API, trace2 provides higer-level event verbs with fixed-fields allowing structured data to be written. This makes post-processing and analysis easier for external tools. Trace2 defines 3 output targets. These are set using the environment variables "GIT_TR2", "GIT_TR2_PERF", and "GIT_TR2_EVENT". These may be set to "1" or to an absolute pathname (just like the current GIT_TRACE). * GIT_TR2 is intended to be a replacement for GIT_TRACE and logs command summary data. * GIT_TR2_PERF is intended as a replacement for GIT_TRACE_PERFORMANCE. It extends the output with columns for the command process, thread, repo, absolute and relative elapsed times. It reports events for child process start/stop, thread start/stop, and per-thread function nesting. * GIT_TR2_EVENT is a new structured format. It writes event data as a series of JSON records. Calls to trace2 functions log to any of the 3 output targets enabled without the need to call different trace_printf* or trace_performance* routines. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-15mingw: safe-guard a bit more against getenv() problemsLibravatar Johannes Schindelin1-1/+1
Running up to v2.21.0, we fixed two bugs that were made prominent by the Windows-specific change to retain copies of only the 30 latest getenv() calls' returned strings, invalidating any copies of previous getenv() calls' return values. While this really shines a light onto bugs of the form where we hold onto getenv()'s return values without copying them, it is also a real problem for users. And even if Jeff King's patches merged via 773e408881 (Merge branch 'jk/save-getenv-result', 2019-01-29) provide further work on that front, we are far from done. Just one example: on Windows, we unset environment variables when spawning new processes, which potentially invalidates strings that were previously obtained via getenv(), and therefore we have to duplicate environment values that are somehow involved in spawning new processes (e.g. GIT_MAN_VIEWER in show_man_page()). We do not have a chance to investigate, let address, all of those issues in time for v2.21.0, so let's at least help Windows users by increasing the number of getenv() calls' return values that are kept valid. The number 64 was determined by looking at the average number of getenv() calls per process in the entire test suite run on Windows (which is around 40) and then adding a bit for good measure. And it is a power of two (which would have hit yesterday's theme perfectly). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13Merge branch 'js/mingw-host-cpu'Libravatar Junio C Hamano1-19/+0
Windows update. * js/mingw-host-cpu: mingw: use a more canonical method to fix the CPU reporting
2019-02-13Merge branch 'nd/fileno-may-be-macro'Libravatar Junio C Hamano1-0/+7
* nd/fileno-may-be-macro: git-compat-util: work around fileno(fp) that is a macro
2019-02-13mingw: use a more canonical method to fix the CPU reportingLibravatar Johannes Schindelin1-19/+0
In `git version --build-options`, we report also the CPU, but in Git for Windows we actually cross-compile the 32-bit version in a 64-bit Git for Windows, so we cannot rely on the auto-detected value. In 3815f64b0dd9 (mingw: fix CPU reporting in `git version --build-options`, 2019-02-07), we fixed this by a Windows-only workaround, making use of magic pre-processor constants, which works in GCC, but most likely not all C compilers. As pointed out by Eric Sunshine, there is a better way, anyway: to set the Makefile variable HOST_CPU explicitly for cross-compiled Git. So let's do that! This reverts commit 3815f64b0dd983bdbf9242a0547706d5d81cb3e6 partially. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-12git-compat-util: work around fileno(fp) that is a macroLibravatar Duy Nguyen1-0/+7
On various BSD's, fileno(fp) is implemented as a macro that directly accesses the fields in the FILE * object, which breaks a function that accepts a "void *fp" parameter and calls fileno(fp) and expect it to work. Work it around by adding a compile-time knob FILENO_IS_A_MACRO that inserts a real helper function in the middle of the callchain. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-08Merge branch 'js/mingw-host-cpu'Libravatar Junio C Hamano1-0/+19
Windows update. * js/mingw-host-cpu: mingw: fix CPU reporting in `git version --build-options`
2019-02-07mingw: fix CPU reporting in `git version --build-options`Libravatar Johannes Schindelin1-0/+19
We cannot rely on `uname -m` in Git for Windows' SDK to tell us what architecture we are compiling for, as we can compile both 32-bit and 64-bit `git.exe` from a 64-bit SDK, but the `uname -m` in that SDK will always report `x86_64`. So let's go back to our original design. And make it explicitly Windows-specific. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-06Merge branch 'js/vsts-ci'Libravatar Junio C Hamano1-1/+1
Prepare to run test suite on Azure Pipeline. * js/vsts-ci: (22 commits) test-date: drop unused parameter to getnanos() ci: parallelize testing on Windows ci: speed up Windows phase tests: optionally skip bin-wrappers/ t0061: workaround issues with --with-dashes and RUNTIME_PREFIX tests: add t/helper/ to the PATH with --with-dashes mingw: try to work around issues with the test cleanup tests: include detailed trace logs with --write-junit-xml upon failure tests: avoid calling Perl just to determine file sizes README: add a build badge (status of the Azure Pipelines build) mingw: be more generous when wrapping up the setitimer() emulation ci: use git-sdk-64-minimal build artifact ci: add a Windows job to the Azure Pipelines definition Add a build definition for Azure DevOps ci/lib.sh: add support for Azure Pipelines tests: optionally write results as JUnit-style .xml test-date: add a subcommand to measure times in shell scripts ci: use a junction on Windows instead of a symlink ci: inherit --jobs via MAKEFLAGS in run-build-and-tests ci/lib.sh: encapsulate Travis-specific things ...
2019-02-06Merge branch 'tb/utf-16-le-with-explicit-bom'Libravatar Junio C Hamano1-1/+1
A new encoding UTF-16LE-BOM has been invented to force encoding to UTF-16 with BOM in little endian byte order, which cannot be directly generated by using iconv. * tb/utf-16-le-with-explicit-bom: Support working-tree-encoding "UTF-16LE-BOM"
2019-02-05Merge branch 'js/mingw-unc-path-w-backslashes'Libravatar Junio C Hamano1-1/+76
In Git for Windows, "git clone \\server\share\path" etc. that uses UNC paths from command line had bad interaction with its shell emulation. * js/mingw-unc-path-w-backslashes: mingw: special-case arguments to `sh` mingw (t5580): document bug when cloning from backslashed UNC paths
2019-02-05Merge branch 'sg/obstack-cast-function-type-fix'Libravatar Junio C Hamano2-15/+20
The compat/obstack code had casts that -Wcast-function-type compilation option found questionable. * sg/obstack-cast-function-type-fix: compat/obstack: fix -Wcast-function-type warnings
2019-01-31Support working-tree-encoding "UTF-16LE-BOM"Libravatar Torsten Bögershausen1-1/+1
Users who want UTF-16 files in the working tree set the .gitattributes like this: test.txt working-tree-encoding=UTF-16 The unicode standard itself defines 3 allowed ways how to encode UTF-16. The following 3 versions convert all back to 'g' 'i' 't' in UTF-8: a) UTF-16, without BOM, big endian: $ printf "\000g\000i\000t" | iconv -f UTF-16 -t UTF-8 | od -c 0000000 g i t b) UTF-16, with BOM, little endian: $ printf "\377\376g\000i\000t\000" | iconv -f UTF-16 -t UTF-8 | od -c 0000000 g i t c) UTF-16, with BOM, big endian: $ printf "\376\377\000g\000i\000t" | iconv -f UTF-16 -t UTF-8 | od -c 0000000 g i t Git uses libiconv to convert from UTF-8 in the index into ITF-16 in the working tree. After a checkout, the resulting file has a BOM and is encoded in "UTF-16", in the version (c) above. This is what iconv generates, more details follow below. iconv (and libiconv) can generate UTF-16, UTF-16LE or UTF-16BE: d) UTF-16 $ printf 'git' | iconv -f UTF-8 -t UTF-16 | od -c 0000000 376 377 \0 g \0 i \0 t e) UTF-16LE $ printf 'git' | iconv -f UTF-8 -t UTF-16LE | od -c 0000000 g \0 i \0 t \0 f) UTF-16BE $ printf 'git' | iconv -f UTF-8 -t UTF-16BE | od -c 0000000 \0 g \0 i \0 t There is no way to generate version (b) from above in a Git working tree, but that is what some applications need. (All fully unicode aware applications should be able to read all 3 variants, but in practise we are not there yet). When producing UTF-16 as an output, iconv generates the big endian version with a BOM. (big endian is probably chosen for historical reasons). iconv can produce UTF-16 files with little endianess by using "UTF-16LE" as encoding, and that file does not have a BOM. Not all users (especially under Windows) are happy with this. Some tools are not fully unicode aware and can only handle version (b). Today there is no way to produce version (b) with iconv (or libiconv). Looking into the history of iconv, it seems as if version (c) will be used in all future iconv versions (for compatibility reasons). Solve this dilemma and introduce a Git-specific "UTF-16LE-BOM". libiconv can not handle the encoding, so Git pick it up, handles the BOM and uses libiconv to convert the rest of the stream. (UTF-16BE-BOM is added for consistency) Rported-by: Adrián Gimeno Balaguer <adrigibal@gmail.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-29mingw: be more generous when wrapping up the setitimer() emulationLibravatar Johannes Schindelin1-1/+1
Every once in a while, the Azure Pipeline fails with some semi-random error: timer thread did not terminate timely This error message means that the thread that is used to emulate the setitimer() function did not terminate within 1,000 milliseconds. The most likely explanation (and therefore the one we should assume to be true, according to Occam's Razor) is that the timeout of one second is simply not enough because we try to run so many tasks in parallel. So let's give it ten seconds instead of only one. That should be enough. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-18Merge branch 'rb/hpe'Libravatar Junio C Hamano1-0/+8
Portability updates for the HPE NonStop platform. * rb/hpe: compat/regex/regcomp.c: define intptr_t and uintptr_t on NonStop git-compat-util.h: add FLOSS headers for HPE NonStop config.mak.uname: support for modern HPE NonStop config. transport-helper: drop read/write errno checks transport-helper: use xread instead of read
2019-01-18mingw: special-case arguments to `sh`Libravatar Johannes Schindelin1-1/+76
The MSYS2 runtime does its best to emulate the command-line wildcard expansion and de-quoting which would be performed by the calling Unix shell on Unix systems. Those Unix shell quoting rules differ from the quoting rules applying to Windows' cmd and Powershell, making it a little awkward to quote command-line parameters properly when spawning other processes. In particular, git.exe passes arguments to subprocesses that are *not* intended to be interpreted as wildcards, and if they contain backslashes, those are not to be interpreted as escape characters, e.g. when passing Windows paths. Note: this is only a problem when calling MSYS2 executables, not when calling MINGW executables such as git.exe. However, we do call MSYS2 executables frequently, most notably when setting the use_shell flag in the child_process structure. There is no elegant way to determine whether the .exe file to be executed is an MSYS2 program or a MINGW one. But since the use case of passing a command line through the shell is so prevalent, we need to work around this issue at least when executing sh.exe. Let's introduce an ugly, hard-coded test whether argv[0] is "sh", and whether it refers to the MSYS2 Bash, to determine whether we need to quote the arguments differently than usual. That still does not fix the issue completely, but at least it is something. Incidentally, this also fixes the problem where `git clone \\server\repo` failed due to incorrect handling of the backslashes when handing the path to the git-upload-pack process. Further, we need to take care to quote not only whitespace and backslashes, but also curly brackets. As aliases frequently go through the MSYS2 Bash, and as aliases frequently get parameters such as HEAD@{yesterday}, this is really important. As an early version of this patch broke this, let's make sure that this does not regress by adding a test case for that. Helped-by: Kim Gybels <kgybels@infogroep.be> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-17compat/obstack: fix -Wcast-function-type warningsLibravatar SZEDER Gábor2-15/+20
GCC 8 introduced the new -Wcast-function-type warning, which is implied by -Wextra (which, in turn is enabled in our DEVELOPER flags). When building Git with GCC 8 and this warning enabled on a non-glibc platform [1], one is greeted with a screenful of compiler warnings/errors: compat/obstack.c: In function '_obstack_begin': compat/obstack.c:162:17: error: cast between incompatible function types from 'void * (*)(long int)' to 'struct _obstack_chunk * (*)(void *, long int)' [-Werror=cast-function-type] h->chunkfun = (struct _obstack_chunk * (*)(void *, long)) chunkfun; ^ compat/obstack.c:163:16: error: cast between incompatible function types from 'void (*)(void *)' to 'void (*)(void *, struct _obstack_chunk *)' [-Werror=cast-function-type] h->freefun = (void (*) (void *, struct _obstack_chunk *)) freefun; ^ compat/obstack.c:116:8: error: cast between incompatible function types from 'struct _obstack_chunk * (*)(void *, long int)' to 'struct _obstack_chunk * (*)(long int)' [-Werror=cast-function-type] : (*(struct _obstack_chunk *(*) (long)) (h)->chunkfun) ((size))) ^ compat/obstack.c:168:22: note: in expansion of macro 'CALL_CHUNKFUN' chunk = h->chunk = CALL_CHUNKFUN (h, h -> chunk_size); ^~~~~~~~~~~~~ <snip> 'struct obstack' stores pointers to two functions to allocate and free "chunks", and depending on how obstack is used, these functions take either one parameter (like standard malloc() and free() do; this is how we use it in 'kwset.c') or two parameters. Presumably to reduce memory footprint, a single field is used to store the function pointer for both signatures, and then it's casted to the appropriate signature when the function pointer is accessed. These casts between function pointers with different number of parameters are what trigger those compiler errors. Modify 'struct obstack' to use unions to store function pointers with different signatures, and then use the union member with the appropriate signature when accessing these function pointers. This eliminates the need for those casts, and thus avoids this compiler error. [1] Compiling 'compat/obstack.c' on a platform with glibc is sort of a noop, see the comment before '# define ELIDE_CODE', so this is not an issue on common Linux distros. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-14Merge branch 'tb/use-common-win32-pathfuncs-on-cygwin'Libravatar Junio C Hamano6-69/+49
Cygwin update. * tb/use-common-win32-pathfuncs-on-cygwin: git clone <url> C:\cygwin\home\USER\repo' is working (again)
2019-01-03compat/regex/regcomp.c: define intptr_t and uintptr_t on NonStopLibravatar Randall S. Becker1-0/+8
The system definition header files on HPE NonStop do not define intptr_t and uintptr_t as do other platforms. These typedefs are added specifically wrapped in a __TANDEM ifdef. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>