summaryrefslogtreecommitdiff
path: root/tests/core/buffer.c
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* fileops: rename to "futils.h" to match function signaturesPatrick Steinhardt2019-07-201-1/+1
| | | | | | | | | 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.
* Convert usage of `git_buf_free` to new `git_buf_dispose`Patrick Steinhardt2018-06-101-46/+46
|
* patch parsing: squash some memory leaksEdward Thomson2016-05-261-0/+2
|
* git_buf: decode base85 inputsEdward Thomson2016-05-261-0/+36
|
* git_futils_mkdir_*: make a relative-to-base mkdirEdward Thomson2015-09-171-1/+1
| | | | | | | | | | | | Untangle git_futils_mkdir from git_futils_mkdir_ext - the latter assumes that we own everything beneath the base, as if it were being called with a base of the repository or working directory, and is tailored towards checkout and ensuring that there is no bogosity beneath the base that must be cleaned up. This is (at best) slow and (at worst) unsafe in the larger context of a filesystem where we do not own things and cannot do things like unlink symlinks that are in our way.
* buffer: make use of EINVALID for growing a borrowed bufferCarlos Martín Nieto2015-06-241-1/+1
| | | | | This explains more closely what happens. While here, set an error message.
* buffer: don't allow growing borrowed buffersCarlos Martín Nieto2015-06-241-0/+13
| | | | | | | | | | When we don't own a buffer (asize=0) we currently allow the usage of grow to copy the memory into a buffer we do own. This muddles the meaning of grow, and lets us be a bit cavalier with ownership semantics. Don't allow this any more. Usage of grow should be restricted to buffers which we know own their own memory. If unsure, we must not attempt to modify it.
* git_buf_text_lf_to_crlf: allow mixed line endingsEdward Thomson2015-06-221-8/+31
| | | | | Allow files to have mixed line endings instead of skipping processing on them.
* Make binary detection work similar to vanilla gitSven Strickroth2015-01-201-1/+1
| | | | | | Main change: Don't treat chars > 128 as non-printable (common in UTF-8 files) Signed-off-by: Sven Strickroth <email@cs-ware.de>
* buffer: Do not `put` anything if len is 0Vicent Marti2014-11-211-3/+2
|
* hashsig: Export as a `sys` headervmg/hashsigVicent Marti2014-10-011-1/+1
|
* Introduce git_buf_decode_base64Edward Thomson2014-08-151-8/+29
| | | | Decode base64-encoded text into a git_buf
* crlf: pass-through mixed EOL buffers from LF->CRLFcmn/mixed-eol-passthroughCarlos Martín Nieto2014-06-231-18/+8
| | | | | | | | | | When checking out files, we're performing conversion into the user's native line endings, but we only want to do it for files which have consistent line endings. Refuse to perform the conversion for mixed-EOL files. The CRLF->LF filter is left as-is, as that conversion is considered to be normalization by git and should force a conversion of the line endings.
* patch: emit binary patches (optionally)Edward Thomson2014-04-221-0/+20
|
* Add efficient git_buf join3 APIRussell Belfer2014-04-011-0/+32
| | | | | | | There are a few places where we need to join three strings to assemble a path. This adds a simple join3 function to avoid the comparatively expensive join_n (which calls strlen on each string twice).
* add unit tests for git_buf_join corner casesPatrick Reynolds2014-01-201-0/+31
|
* Rename tests-clar to testsBen Straub2013-11-141-0/+1039
View Lorry Controller Status