|
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.
|
|
|
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.
|
|
|
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.
|
|
|
ecf4f33a
|
2018-02-08T11:14:48
|
|
Convert usage of `git_buf_free` to new `git_buf_dispose`
|
|
6278fbc5
|
2015-09-24T09:40:42
|
|
patch parsing: squash some memory leaks
|
|
|
5b78dbdb
|
2015-07-09T13:04:10
|
|
git_buf: decode base85 inputs
|
|
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.
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
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>
|
|
92e0b679
|
2014-11-21T13:31:30
|
|
buffer: Do not `put` anything if len is 0
|
|
|
737b5051
|
2014-10-01T12:03:24
|
|
hashsig: Export as a `sys` header
|
|
|
e003f83a
|
2014-07-31T15:14:56
|
|
Introduce git_buf_decode_base64
Decode base64-encoded text into a git_buf
|
|
|
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.
|
|
|
e349ed50
|
2014-04-22T14:58:33
|
|
patch: emit binary patches (optionally)
|
|
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).
|
|
abdaf936
|
2014-01-20T11:42:12
|
|
add unit tests for git_buf_join corner cases
|
|
17820381
|
2013-11-14T14:05:52
|
|
Rename tests-clar to tests
|