summaryrefslogtreecommitdiff
path: root/tests/core
Commit message (Collapse)AuthorAgeFilesLines
* sha1: tests should use hashes, not oid computationEdward Thomson2021-11-221-11/+17
| | | | | | The tests that examine sha1 behavior (including collision detection) should test against the hash functionality directly, not indirectly using the oid functions.
* util: don't include unnecessary system librariesEdward Thomson2021-11-225-5/+0
| | | | Remove some unnecessary includes from utility code.
* utf8: include `utf8.h` in testsEdward Thomson2021-11-191-0/+1
|
* tests: declare functions statically where appropriateEdward Thomson2021-11-111-1/+3
|
* path: separate git-specific path functions from utilEdward Thomson2021-11-0911-219/+211
| | | | | | Introduce `git_fs_path`, which operates on generic filesystem paths. `git_path` will be kept for only git-specific path functionality (for example, checking for `.git` in a path).
* libgit2_clar is now libgit2_testsMartin Kühl2021-10-281-1/+1
| | | | | | in #6083 the test runner was renamed to libgit2_tests, but not all references to the old name were updated. this change changes all of them to use the new name.
* str: introduce `git_str` for internal, `git_buf` is externalethomson/gitstrEdward Thomson2021-10-1715-637/+688
| | | | | | | | | | | | | | | | | | | | | | | | | | | libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.
* hash: hash functions operate on byte arrays not git_oidsEdward Thomson2021-10-021-2/+2
| | | | | | Separate the concerns of the hash functions from the git_oid functions. The git_oid structure will need to understand either SHA1 or SHA256; the hash functions should only deal with the appropriate one of these.
* hash: accept the algorithm in inputsEdward Thomson2021-10-011-1/+1
|
* buf: common_prefix takes a string arrayethomson/strarrayEdward Thomson2021-09-261-22/+7
| | | | | | `git_strarray` is a public-facing type. Change `git_buf_text_common_prefix` to not use it, and just take an array of strings instead.
* common: support custom repository extensionsethomson/extensionsEdward Thomson2021-09-041-0/+46
| | | | | | | | | | Allow users to specify additional repository extensions that they want to support. For example, callers can specify that they support `preciousObjects` and then may open repositories that support `extensions.preciousObjects`. Similarly, callers may opt out of supporting extensions that the library itself supports.
* util: introduce `git__strlcmp`Edward Thomson2021-09-011-0/+11
| | | | | | | Introduce a utility function that compares a NUL terminated string to a possibly not-NUL terminated string with length. This is similar to `strncmp` but with an added check to ensure that the lengths match (not just the `size` portion of the two strings).
* Merge remote-tracking branch 'origin/main' into cgraph-writelhchavez2021-08-264-15/+15
|\
| * Merge pull request #6006 from boretrk/c11-warningsEdward Thomson2021-08-251-5/+5
| |\ | | | | | | GCC C11 warnings
| | * win32: name the dummy union in GIT_REPARSE_DATA_BUFFERPeter Pettersson2021-08-251-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | Instead of buf->"typeofbuffer"ReparseBuffer the members will be referenced with buf->ReparseBuffer."typeofbuffer" https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_reparse_data_buffer?redirectedfrom=MSDN calls the union DUMMYUNIONNAME but that looks a bit cluttered.
| * | Proof-of-concept for a more aggressive GIT_UNUSED()lhchavez2021-08-082-4/+4
| | | | | | | | | | | | | | | | | | This adds a `-Wunused-result`-proof `GIT_UNUSED()`, just to demonstrate that it works. With this, sortedcache.h is now completely `GIT_WARN_UNUSED_RESULT`-annotated!
| * | Introduce GIT_WARN_UNUSED_RESULTlhchavez2021-08-081-6/+6
| |/ | | | | | | | | This change adds the GIT_WARN_UNUSED_RESULT annotation, which makes the compiler warn when a return result is not used. This avoids bugs.
* | Make the defaultable fields defaultablelhchavez2021-08-261-0/+8
|/ | | | Also, add `git_commit_graph_writer_options_init`!
* stdint constants in test suiteCalvin Buckley2021-07-073-238/+238
| | | | | | | | | | Passes w/ gcc 11 on Fedora x64. Protip: So you don;t have to suffer, ``` perl -pe 's/(-?(?:0x)?[A-Fa-f0-9]+)([Uu])?[Ll][Ll]/\U$2INT64_C(\E$1)/mg' ```
* buf: remove internal `git_buf_text` namespaceEdward Thomson2021-05-111-45/+44
| | | | | The `git_buf_text` namespace is unnecessary and strange. Remove it, just keep the functions prefixed with `git_buf`.
* utf8: introduce git_utf8_char_lengthEdward Thomson2021-04-141-0/+19
| | | | | Introduce a function to determine the number of Unicode characters in a given UTF-8 string.
* blob: add git_blob_filter_options_initEdward Thomson2021-01-051-0/+5
| | | | | | The `git_blob_filter_options_init` function should be included, to allow callers in FFI environments to let us initialize an options structure for them.
* Add tests for `git__multiply_int64_overflow`lhchavez2020-12-192-0/+255
| | | | | | | | | As it turns out, the implementation of `git__multiply_int64_overflow` is full of edge cases and tricky arithmetic. That means that it should have unit tests. As a result, a bug in `git__strntol64` was found (and fixed!) in clang+32-bit.
* path: remove unused git_path_topdirEdward Thomson2020-11-271-27/+1
|
* settings: localize global dataEdward Thomson2020-10-111-1/+1
| | | | | Move the settings global data teardown into its own separate function, instead of intermingled with the global state.
* clar: include the function nameethomson/clar_tapEdward Thomson2020-06-054-15/+16
|
* assert: allow non-int returning functions to assertethomson/assert_macrosEdward Thomson2020-05-111-0/+53
| | | | | | | | | | Include GIT_ASSERT_WITH_RETVAL and GIT_ASSERT_ARG_WITH_RETVAL so that functions that do not return int (or more precisely, where `-1` would not be an error code) can assert. This allows functions that return, eg, NULL on an error code to do that by passing the return value (in this example, `NULL`) as a second parameter to the GIT_ASSERT_WITH_RETVAL functions.
* assert: optionally fall-back to assert(3)Edward Thomson2020-05-111-0/+2
| | | | | | | | | Fall back to the system assert(3) in debug builds, which may aide in debugging. "Safe" assertions can be enabled in debug builds by setting GIT_ASSERT_HARD=0. Similarly, hard assertions can be enabled in release builds by setting GIT_ASSERT_HARD to nonzero.
* Introduce GIT_ASSERT macrosEdward Thomson2020-05-111-0/+39
| | | | | | | | | | | | Provide macros to replace usages of `assert`. A true `assert` is punishing as a library. Instead we should do our best to not crash. GIT_ASSERT_ARG(x) will now assert that the given argument complies to some format and sets an error message and returns `-1` if it does not. GIT_ASSERT(x) is for internal usage, and available as an internal consistency check. It will set an error message and return `-1` in the event of failure.
* win32: test relative symlinksethomson/canonicalPatrick Steinhardt2020-03-101-0/+20
| | | | Ensure that we don't canonicalize symlink targets.
* win32: fix relative symlinks pointing into dirsPatrick Steinhardt2020-01-101-0/+27
| | | | | | | | | | | | | | | | | | On Windows platforms, we need some logic to emulate symlink(3P) defined by POSIX. As unprivileged symlinks on Windows are a rather new feature, our current implementation is comparatively new and still has some rough edges in special cases. One such case is relative symlinks. While relative symlinks to files in the same directory work as expected, libgit2 currently fails to create reltaive symlinks pointing into other directories. This is due to the fact that we forgot to translate the Unix-style target path to Windows-style. Most importantly, we are currently not converting directory separators from "/" to "\". Fix the issue by calling `git_win32_path_canonicalize` on the target. Add a test that verifies our ability to create such relative links across directories.
* internal: use off64_t instead of git_off_tethomson/off_tEdward Thomson2019-11-251-1/+1
| | | | Prefer `off64_t` internally.
* Merge pull request #5226 from pks-t/pks/regexp-apiEdward Thomson2019-09-282-120/+213
|\ | | | | regexp: implement a new regular expression API
| * posix: remove superseded POSIX regex wrappersPatrick Steinhardt2019-09-211-120/+0
| | | | | | | | | | | | The old POSIX regex wrappers have been superseded by our own regexp API that provides a higher-level abstraction. Remove the POSIX wrappers in favor of the new one.
| * regexp: implement new regular expression APIPatrick Steinhardt2019-09-211-0/+213
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently support a set of different regular expression backends with PCRE, PCRE2, regcomp(3P) and regcomp_l(3). The current implementation of this is done via a simple POSIX wrapper that either directly uses supplied functions or that is a very small wrapper. To support PCRE and PCRE2, we use their provided <pcreposix.h> and <pcre2posix.h> wrappers. These wrappers are implemented in such a way that the accompanying libraries pcre-posix and pcre2-posix provide the same symbols as the libc ones, namely regcomp(3P) et al. This works out on some systems just fine, most importantly on glibc-based ones, where the regular expression functions are implemented as weak aliases and thus get overridden by linking in the pcre{,2}-posix library. On other systems we depend on the linking order of libc and pcre library, and as libc always comes first we will end up with the functions of the libc implementation. As a result, we may use the structures `regex_t` and `regmatch_t` declared by <pcre{,2}posix.h>, but use functions defined by the libc, leading to segfaults. The issue is not easily solvable. Somed distributions like Debian have resolved this by patching PCRE and PCRE2 to carry custom prefixes to all the POSIX function wrappers. But this is not supported by upstream and thus inherently unportable between distributions. We could instead try to modify linking order, but this starts becoming fragile and will not work e.g. when libgit2 is loaded via dlopen(3P) or similar ways. In the end, this means that we simply cannot use the POSIX wrappers provided by the PCRE libraries at all. Thus, this commit introduces a new regular expression API. The new API is on a tad higher level than the previous POSIX abstraction layer, as it tries to abstract away any non-portable flags like e.g. REG_EXTENDED, which has no equivalents in all of our supported backends. As there are no users of POSIX regular expressions that do _not_ reguest REG_EXTENDED this is fine to be abstracted away, though. Due to the API being higher-level than before, it should generally be a tad easier to use than the previous one. Note: ideally, the new API would've been called `git_regex_foobar` with a file "regex.h" and "regex.c". Unfortunately, this is currently impossible to implement due to naming clashes between the then-existing "regex.h" and <regex.h> provided by the libc. As we add the source directory of libgit2 to the header search path, an include of <regex.h> would always find our own "regex.h". Thus, we have to take the bitter pill of adding one more character to all the functions to disambiguate the includes. To improve guarantees around cross-backend compatibility, this commit also brings along an improved regular expression test suite core::regexp.
* | buffer: fix printing into out-of-memory bufferPatrick Steinhardt2019-09-211-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before printing into a `git_buf` structure, we always call `ENSURE_SIZE` first. This macro will reallocate the buffer as-needed depending on whether the current amount of allocated bytes is sufficient or not. If `asize` is big enough, then it will just do nothing, otherwise it will call out to `git_buf_try_grow`. But in fact, it is insufficient to only check `asize`. When we fail to allocate any more bytes e.g. via `git_buf_try_grow`, then we set the buffer's pointer to `git_buf__oom`. Note that we touch neither `asize` nor `size`. So if we just check `asize > targetsize`, then we will happily let the caller of `ENSURE_SIZE` proceed with an out-of-memory buffer. As a result, we will print all bytes into the out-of-memory buffer instead, resulting in an out-of-bounds write. Fix the issue by having `ENSURE_SIZE` verify that the buffer is not marked as OOM. Add a test to verify that we're not writing into the OOM buffer.
* | buffer: fix infinite loop when growing buffersPatrick Steinhardt2019-09-211-3/+19
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | When growing buffers, we repeatedly multiply the currently allocated number of bytes by 1.5 until it exceeds the requested number of bytes. This has two major problems: 1. If the current number of bytes is tiny and one wishes to resize to a comparatively huge number of bytes, then we may need to loop thousands of times. 2. If resizing to a value close to `SIZE_MAX` (which would fail anyway), then we probably hit an infinite loop as multiplying the current amount of bytes will repeatedly result in integer overflows. When reallocating buffers, one typically chooses values close to 1.5 to enable re-use of resulting memory holes in later reallocations. But because of this, it really only makes sense to use a factor of 1.5 _once_, but not looping until we finally are able to fit it. Thus, we can completely avoid the loop and just opt for the much simpler algorithm of multiplying with 1.5 once and, if the result doesn't fit, just use the target size. This avoids both problems of looping extensively and hitting overflows. This commit also adds a test that would've previously resulted in an infinite loop.
* util: do not perform allocations in insertsortPatrick Steinhardt2019-08-231-0/+90
| | | | | | | | | | | | | | | | | | | | | Our hand-rolled fallback sorting function `git__insertsort_r` does an in-place sort of the given array. As elements may not necessarily be pointers, it needs a way of swapping two values of arbitrary size, which is currently implemented by allocating a temporary buffer of the element's size. This is problematic, though, as the emulated `qsort` interface doesn't provide any return values and thus cannot signal an error if allocation of that temporary buffer has failed. Convert the function to swap via a temporary buffer allocated on the stack. Like this, it can `memcpy` contents of both elements in small batches without requiring a heap allocation. The buffer size has been chosen such that in most cases, a single iteration of copying will suffice. Most importantly, it can fully contain `git_oid` structures and pointers. Add a bunch of tests for the `git__qsort_r` interface to verify nothing breaks. Furthermore, this removes the declaration of `git__insertsort_r` and makes it static as it is not used anywhere else.
* win32: fix symlinks to relative file targetsPatrick Steinhardt2019-07-201-0/+24
| | | | | | | | | | | | | | | When creating a symlink in Windows, one needs to tell Windows whether the symlink should be a file or directory symlink. To determine which flag to pass, we call `GetFileAttributesW` on the target file to see whether it is a directory and then pass the flag accordingly. The problem though is if create a symlink with a relative target path, then we will check that relative path while not necessarily being inside of the working directory where the symlink is to be created. Thus, getting its attributes will either fail or return attributes of the wrong target. Fix this by resolving the target path relative to the directory in which the symlink is to be created.
* tests: core: improve symlink test coveragePatrick Steinhardt2019-07-203-9/+49
| | | | | | | | Add two more tests to verify that we're not deleting symlink targets, but the symlinks themselves. Furthermore, convert several `cl_skip`s on Win32 to conditional skips depending on whether the clar sandbox supports symlinks or not. Windows is grown up now and may allow unprivileged symlinks if the machine has been configured accordingly.
* tests: core: add missing asserts for several function callsPatrick Steinhardt2019-07-201-5/+5
| | | | | | | Several function calls to `p_stat` and `p_close` have no verification if they actually succeeded. As these functions _may_ fail and as we also want to make sure that we're not doing anything dumb, let's check them, too.
* fileops: rename to "futils.h" to match function signaturesPatrick Steinhardt2019-07-209-9/+9
| | | | | | | | | Our file utils functions all have a "futils" prefix, e.g. `git_futils_touch`. One would thus naturally guess that their definitions and implementation would live in files "futils.h" and "futils.c", respectively, but in fact they live in "fileops.h". Rename the files to match expectations.
* win32: cast WinAPI to void * before castingEdward Thomson2019-06-241-2/+2
| | | | | | | GetProcAddress is prototyped to return a `FARPROC`, which is meant to be a generic function pointer. It's literally `int (FAR WINAPI * FARPROC)()` which gcc complains if you attempt to cast to a `void (*)(GIT_SRWLOCK *)`. Cast to a `void *` before casting to avoid warnings about the arguments.
* Merge pull request #5110 from pks-t/pks/wildmatchEdward Thomson2019-06-151-0/+248
|\ | | | | Replace fnmatch with wildmatch
| * wildmatch: import wildmatch from git.gitPatrick Steinhardt2019-06-151-0/+248
| | | | | | | | | | | | | | | | | | | | | | In commit 70a8fc999d (stop using fnmatch (either native or compat), 2014-02-15), upstream git has switched over all code from their internal fnmatch copy to its new wildmatch code. We haven't followed suit, and thus have developed some incompatibilities in how we match regular expressions. Import git's wildmatch from v2.22.0 and add a test suite based on their t3070-wildmatch.sh tests.
* | posix: remove `p_fallocate` abstractionPatrick Steinhardt2019-06-141-41/+0
|/ | | | | | | | | | | | | | | By now, we have repeatedly failed to provide a nice cross-platform implementation of `p_fallocate`. Recent tries to do that escalated quite fast to a set of different CMake checks, implementations, fallbacks, etc., which started to look real awkward to maintain. In fact, `p_fallocate` had only been introduced in commit 4e3949b73 (tests: test that largefiles can be read through the tree API, 2019-01-30) to support a test with large files, but given the maintenance costs it just seems not to be worht it. As we have removed the sole user of `p_fallocate` in the previous commit, let's drop it altogether.
* apply: add an options struct initializerethomson/opts_initEdward Thomson2019-06-141-0/+5
|
* Rename opt init functions to `options_init`Edward Thomson2019-06-141-16/+16
| | | | | | | | | | | | | In libgit2 nomenclature, when we need to verb a direct object, we name a function `git_directobject_verb`. Thus, if we need to init an options structure named `git_foo_options`, then the name of the function that does that should be `git_foo_options_init`. The previous names of `git_foo_init_options` is close - it _sounds_ as if it's initializing the options of a `foo`, but in fact `git_foo_options` is its own noun that should be respected. Deprecate the old names; they'll now call directly to the new ones.
* core::posix: skip some locale tests on win32Edward Thomson2019-05-191-7/+18
|
* tests: regcomp: use proper character classesEdward Thomson2019-05-191-2/+2
| | | | | The '[[:digit:]]' and '[[:alpha:]]' classes require double brackets, not single.
View Lorry Controller Status