In `diff_print_patch_file` we try to avoid printing the file if we're not sure
that there will be some content. This works fine if we have any later functions
that might get called as part of printing. But when given the format
`GIT_DIFF_FORMAT_PATCH_HEADER`, this is the only function to get called.
Add the binary and hunk functions to those to be called when given this option
and have them exit after printing the header. This takes care of printing the
header if we would be issuing a hunk, but we skip that part.
Fixes a bug likely introduced in
d396819101 (in 1.8.1) whereby
‘proxy_settings.on_status’ would be left uninitialized when using the
‘http-parser’ backend, eventually leading to a segfault in
‘http_parser_execute’. Valgrind would report use of the uninitialized
value like so:
Conditional jump or move depends on uninitialised value(s)
at 0x50CD533: http_parser_execute (http_parser.c:910)
by 0x4928504: git_http_parser_execute (httpparser.c:82)
by 0x4925C42: client_read_and_parse (httpclient.c:1178)
by 0x4926F27: git_http_client_read_response (httpclient.c:1458)
by 0x49255FE: http_stream_read (http.c:427)
by 0x4929B90: git_smart__recv (smart.c:29)
by 0x492C147: git_smart__store_refs (smart_protocol.c:58)
by 0x4929F6C: git_smart__connect (smart.c:171)
by 0x4904DCE: git_remote_connect_ext (remote.c:963)
by 0x48A15D2: clone_into (clone.c:449)
by 0x48A15D2: git__clone (clone.c:546)
by 0x4010E9: main (libgit2-proxy.c:20)
Description: In an older version of libgit2 in git_object_lookup_prefix was a check that repo is valid, but now there is repo->oid_type in the git_object_lookup and must be checked as well
realpath(3) _may_ allocate strings (if the second param is NULL) using
the system allocator. However, callers need an assurance that they can
free memory using git__free. If we made realpath do an allocation, then
make sure that we strdup it into our allocator's memory.
More importantly, avoid this behavior by always providing a buffer to
p_realpath invocations.
Instead of tweaking the `stdalloc` allocator when
`GIT_DEBUG_STRICT_ALLOC` is defined, actually create a debugging
allocator. This allows us to ensure that we are strict about things like
not expecting `malloc(0)` to do something useful, but we can also
introduce an excessively pedantic `realloc` implementation that _always_
creates a new buffer, throws away its original `ptr`, and overwrites the
data that's there with garbage. This may be helpful to identify places
that make assumptions about realloc.
Avoid sloppy aliasing in our (re-)allocation, which is undefined
behavior. This has been problematic before and was helped by `volatile`
(see b62a6a13b2) but that is not
technically correct, and some compilers / architectures do not
understand that `ptr` is changing due to its aliasing.
Just make `git_array_alloc` behave like `realloc`, taking a `void *` and
returning a `void *`.
In attempting to make a clever change that added fetch options as flags,
while keeping ABI and API compatibility, we screwed up. Bitfields in
structs are implementation-specific and are not necessarily ABI
compatible across compilers.
Make `update_fetchhead` a flags value which is weirdly named, but
that's a future problem. This removes the `report_unchanged` option from
API.
Since 3618a2a, `git_error_last` does not return NULL when there was no
error. Adapt to this when testing for a user cancelling a callback but
not setting an error message, testing for `klass` of `GIT_ERROR_NONE`.
