| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Introduce `git_buf_grow_by` to incrementally increase the size of a
`git_buf`, performing an overflow calculation on the growth.
|
| |
|
|
|
| |
Introduce some helper macros to test integer overflow from arithmetic
and set error message appropriately.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When deflating data, we might need to grow the buffer. Currently we
add a guess on top of the currently-allocated buffer size.
When we re-use the buffer, it already has some memory allocated; adding
to that means that we always grow the buffer regardless of how much we
need to use.
Instead, increase on top of the currently-used size. This still leaves
us with the allocated size of the largest object we compress, but it's a
minor pain compared to unbounded growth.
This fixes #2285.
|
| |
|
|
|
| |
And don't terminate if there isn't space for it (since it's binary
data, it's not worth a reallocation).
|
| | |
|
| |
|
|
|
|
|
|
| |
There were some confusing issues mixing up the number of bytes
written to the zstream output buffer with the number of bytes
consumed from the zstream input. This reorganizes the zstream
API and makes it easier to deflate an arbitrarily large input
while still using a fixed size output.
|
| | |
|
| | |
|
| |
|
