tests/core/buffer.c


Log

Author Commit Date CI Message
Patrick Steinhardt 174b7a32 2019-09-19T12:24:06 buffer: fix printing into out-of-memory buffer 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.
Patrick Steinhardt 208f1d7a 2019-09-19T12:46:37 buffer: fix infinite loop when growing buffers 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.
Patrick Steinhardt e54343a4 2019-06-29T09:17:32 fileops: rename to "futils.h" to match function signatures 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.
Patrick Steinhardt ecf4f33a 2018-02-08T11:14:48 Convert usage of `git_buf_free` to new `git_buf_dispose`
Edward Thomson 6278fbc5 2015-09-24T09:40:42 patch parsing: squash some memory leaks
Edward Thomson 5b78dbdb 2015-07-09T13:04:10 git_buf: decode base85 inputs
Edward Thomson ac2fba0e 2015-09-16T15:07:27 git_futils_mkdir_*: make a relative-to-base mkdir 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.
Carlos Martín Nieto a6599235 2015-06-24T19:32:56 buffer: make use of EINVALID for growing a borrowed buffer This explains more closely what happens. While here, set an error message.
Carlos Martín Nieto caab22c0 2015-06-23T15:41:58 buffer: don't allow growing borrowed buffers 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.
Edward Thomson 8293c8f9 2015-06-08T13:51:28 git_buf_text_lf_to_crlf: allow mixed line endings Allow files to have mixed line endings instead of skipping processing on them.
Sven Strickroth 0161e096 2014-11-13T19:30:47 Make binary detection work similar to vanilla git Main change: Don't treat chars > 128 as non-printable (common in UTF-8 files) Signed-off-by: Sven Strickroth <email@cs-ware.de>
Vicent Marti 92e0b679 2014-11-21T13:31:30 buffer: Do not `put` anything if len is 0
Vicent Marti 737b5051 2014-10-01T12:03:24 hashsig: Export as a `sys` header
Edward Thomson e003f83a 2014-07-31T15:14:56 Introduce git_buf_decode_base64 Decode base64-encoded text into a git_buf
Carlos Martín Nieto 5a76ad35 2014-06-19T11:45:46 crlf: pass-through mixed EOL buffers from LF->CRLF 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.
Edward Thomson e349ed50 2014-04-22T14:58:33 patch: emit binary patches (optionally)
Russell Belfer 18234b14 2014-02-21T09:14:16 Add efficient git_buf join3 API 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).
Patrick Reynolds abdaf936 2014-01-20T11:42:12 add unit tests for git_buf_join corner cases
Ben Straub 17820381 2013-11-14T14:05:52 Rename tests-clar to tests