git/test-path-utils.c, branch gitk-resize-error

test helpers: move test-* to t/helper/ subdirectory

2016-04-15T17:12:19Z

This keeps top dir a bit less crowded. And because these programs are for testing purposes, it makes sense that they stay somewhere in t/ Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Merge branch 'jk/tighten-alloc'

2016-02-26T21:37:16Z

Update various codepaths to avoid manually-counted malloc(). * jk/tighten-alloc: (22 commits) ewah: convert to REALLOC_ARRAY, etc convert ewah/bitmap code to use xmalloc diff_populate_gitlink: use a strbuf transport_anonymize_url: use xstrfmt git-compat-util: drop mempcpy compat code sequencer: simplify memory allocation of get_message test-path-utils: fix normalize_path_copy output buffer size fetch-pack: simplify add_sought_entry fast-import: simplify allocation in start_packfile write_untracked_extension: use FLEX_ALLOC helper prepare_{git,shell}_cmd: use argv_array use st_add and st_mult for allocation size computation convert trivial cases to FLEX_ARRAY macros use xmallocz to avoid size arithmetic convert trivial cases to ALLOC_ARRAY convert manual allocations to argv_array argv-array: add detach function add helpers for allocating flex-array structs harden REALLOC_ARRAY and xcalloc against size_t overflow tree-diff: catch integer overflow in combine_diff_path allocation ...

test-path-utils: fix normalize_path_copy output buffer size

2016-02-22T22:51:09Z

The normalize_path_copy function needs an output buffer that is at least as long as its input (it may shrink the path, but never expand it). However, this test program feeds it static PATH_MAX-sized buffers, which have no relation to the input size. In the normalize_ceiling_entry case, we do at least check the size against PATH_MAX and die(), but that case is even more convoluted. We normalize into a fixed-size buffer, free the original, and then replace it with a strdup'd copy of the result. But normalize_path_copy explicitly allows normalizing in-place, so we can simply do that. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

test-path-utils: use xsnprintf in favor of strcpy

2016-02-08T22:42:32Z

This strcpy will never overflow because it's copying from baked-in test data. But we would prefer to avoid strcpy entirely, as it makes it harder to audit for real security bugs. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

t0060: loosen overly strict expectations

2016-01-15T17:26:20Z

The dirname() tests file were developed and tested on only the five platforms available to the developer at the time, namely: Linux (both 32 and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit. http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html (i.e. the POSIX spec) says, in part: If the string pointed to by path consists entirely of the '/' character, basename() shall return a pointer to the string "/". If the string pointed to by path is exactly "//", it is implementation-defined whether "/" or "//" is returned. The thinking behind testing precise, OS-dependent output values was to document that different setups produce different values. However, as the test failures on MacOSX illustrated eloquently: hardcoding pretty much each and every setup's expectations is pretty fragile. This is not limited to the "//" vs "/" case, of course, other inputs are also allowed to produce multiple outputs by the POSIX specs. So let's just test for all allowed values and be done with it. This still documents that Git cannot rely on one particular output value in those cases, so the intention of the original tests is still met. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

t0060: verify that basename() and dirname() work as expected

2016-01-12T18:41:34Z

Unfortunately, some libgen implementations yield outcomes different from what Git expects. For example, mingw-w64-crt provides a basename() function, that shortens `path0/` to `path`! So let's verify that the basename() and dirname() functions we use conform to what Git expects. Derived-from-code-by: Ramsay Jones Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

test-path-utils.c: remove incorrect assumption

2015-10-09T01:03:50Z

In normalize_ceiling_entry(), we test that normalized paths end with slash, *unless* the path to be normalized was already the root directory. However, normalize_path_copy() does not even enforce this condition. Even worse: on Windows, the root directory gets translated into a Windows directory by the Bash before being passed to `git.exe` (or `test-path-utils.exe`), which means that we cannot even know whether the path that was passed to us was the root directory to begin with. This issue has already caused endless hours of trying to "fix" the MSYS2 runtime, only to break other things due to MSYS2 ensuring that the converted path maintains the same state as the input path with respect to any final '/'. So let's just forget about this test. It is non-essential to Git's operation, anyway. Acked-by: Johannes Schindelin Signed-off-by: Ray Donnelly

path-utils test: rename mingw_path function to print_path

2013-10-14T14:32:53Z

mingw_path was introduced in abd4284 to output a mangled path as it is passed as an argument to main(). But the name is misleading because mangling does not come from MinGW, but from MSYS [1]. As abd4284 does not introduce any MSYS or MinGW specific code but just prints out argv[2] as it is passed to main(), give the function the more generic and less confusing name "print_path". [1] http://www.mingw.org/wiki/Posix_path_conversion Signed-off-by: Sebastian Schuberth Signed-off-by: Jonathan Nieder

test: run testcases with POSIX absolute paths on Windows

2013-06-26T18:25:12Z

Some test cases are skipped on Windows by marking with POSIX prereq. This is because arguments look like absolute paths (such as /a/b) for regular Windows programs (*.exe executables, no bash scripts) are changed to Windows paths (like C:/msysgit/a/b). There is no cygpath nor equivalent on msysGit, but it is easy to write one. New subcommand "mingw_path" is added in test-path-utils, so that we can get the expected absolute paths on Windows. E.g. COMMAND LINE Linux output Windows output ================================== ============ =============== test-path-utils mingw_path / / C:/msysgit test-path-utils mingw_path /a/b/ /a/b/ C:/msysgit/a/b/ With this utility, most skipped test cases in t0060 can be turned on to be tested correctly on Windows. Signed-off-by: Jiang Xin Signed-off-by: Junio C Hamano

path.c: refactor relative_path(), not only strip prefix

2013-06-26T16:59:00Z

Original design of relative_path() is simple, just strip the prefix (*base) from the absolute path (*abs). In most cases, we need a real relative path, such as: ../foo, ../../bar. That's why there is another reimplementation (path_relative()) in quote.c. Borrow some codes from path_relative() in quote.c to refactor relative_path() in path.c, so that it could return real relative path, and user can reuse this function without reimplementing his/her own. The function path_relative() in quote.c will be substituted, and I would use the new relative_path() function when implementing the interactive git-clean later. Different results for relative_path() before and after this refactor: abs path base path relative (original) relative (refactor) ======== ========= =================== =================== /a/b /a/b . ./ /a/b/ /a/b . ./ /a /a/b/ /a ../ / /a/b/ / ../../ /a/c /a/b/ /a/c ../c /x/y /a/b/ /x/y ../../x/y a/b/ a/b/ . ./ a/b/ a/b . ./ a a/b a ../ x/y a/b/ x/y ../../x/y a/c a/b a/c ../c (empty) (null) (empty) ./ (empty) (empty) (empty) ./ (empty) /a/b (empty) ./ (null) (null) (null) ./ (null) (empty) (null) ./ (null) /a/b (segfault) ./ You may notice that return value "." has been changed to "./". It is because: * Function quote_path_relative() in quote.c will show the relative path as "./" if abs(in) and base(prefix) are the same. * Function relative_path() is called only once (in setup.c), and it will be OK for the return value as "./" instead of ".". Signed-off-by: Jiang Xin Signed-off-by: Junio C Hamano