summaryrefslogtreecommitdiff
path: root/t/t4034/pascal
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2021-04-01 04:32:24 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2021-04-01 12:54:21 -0700
commitc6854508808dd32e3fc20c5b021c4064d25f6438 (patch)
tree676c646da413b954fb09eb24688d014bcb50ba14 /t/t4034/pascal
parentGit 2.29.3 (diff)
downloadtgif-c6854508808dd32e3fc20c5b021c4064d25f6438.tar.xz
ref-filter: fix NULL check for parse object failure
After we run parse_object_buffer() to get an object's contents, we try to check that the return value wasn't NULL. However, since our "struct object" is a pointer-to-pointer, and we assign like: *obj = parse_object_buffer(...); it's not correct to check: if (!obj) That will always be true, since our double pointer will continue to point to the single pointer (which is itself NULL). This is a regression that was introduced by aa46a0da30 (ref-filter: use oid_object_info() to get object, 2018-07-17); since that commit we'll segfault on a parse failure, as we try to look at the NULL object pointer. There are many ways a parse could fail, but most of them are hard to set up in the tests (it's easy to make a bogus object, but update-ref will refuse to point to it). The test here uses a tag which points to a wrong object type. A parse of just the broken tag object will succeed, but seeing both tag objects in the same process will lead to a parse error (since we'll see the pointed-to object as both types). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t4034/pascal')
0 files changed, 0 insertions, 0 deletions