| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create a custom allocator for the `buf::oom` tests that will fail with
out-of-memory errors in predictable ways. We were previously trying to
guess the way that various allocators on various platforms would fail
in a way such that `malloc`/`realloc` would return `NULL` (instead of
aborting the application, or appearing suspicious to various
instrumentation or static code analysis tools like valgrind.)
Introduce a fake `malloc` and `realloc` that will return `NULL` on
allocations requesting more than 100 bytes. Otherwise, we proxy to the
default allocator. (It's important to use the _default_ allocator, not
just call `malloc`, since the default allocator on Windows CI builds may
be the debugging C runtime allocators which would not be compatible with
a standard `malloc`.)
|
| |
|
|
|
|
| |
On a 32-bit Linux systems, the value large enough to make malloc
guarantee a failure is also large enough that valgrind considers it
"fishy". Skip this test on those systems entirely.
|
| |
|
|
|
|
|
|
|
|
|
| |
On Linux (where we run valgrind) allocate a smaller buffer, but still an
insanely large size. This will cause malloc to fail but will not cause
valgrind to report a likely error with a negative-sized malloc.
Keep the original buffer size on non-Linux platforms: this is
well-tested on them and changing it may be problematic. On macOS, for
example, using the new size causes `malloc` to print a warning to
stderr.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Parse values up to and including `\377` (`0xff`) when unquoting.
Print octal values as an unsigned char when quoting, lest `printf`
think we're talking about negatives.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Introduce `git_buf_grow_by` to incrementally increase the size of a
`git_buf`, performing an overflow calculation on the growth.
|
| | |
|
| |
|
