list-objects-filter: initialize sub-filter structs
commit4eaed7c2f2aed1ef510ff97e7e91fa0cbcbef65d
authorJeff King <peff@peff.net>
Thu, 22 Sep 2022 09:35:33 +0000 (22 05:35 -0400)
committerJunio C Hamano <gitster@pobox.com>
Thu, 22 Sep 2022 19:43:04 +0000 (22 12:43 -0700)
tree57ad61d0262ae2ca7c6e4eb5c985dcca370973be
parentc54980ab83661e8e290003fbd5ab44b12e4e77b1
list-objects-filter: initialize sub-filter structs

Since commit c54980ab83 (list-objects-filter: convert filter_spec to a
strbuf, 2022-09-11), building with SANITIZE=undefined triggers an error
in t5616.

The problem is that we end up with a strbuf that has been
zero-initialized instead of via STRBUF_INIT. Feeding that strbuf to
strbuf_addbuf() in list_objects_filter_copy() means we will call memcpy
like:

   memcpy(some_actual_buffer, NULL, 0);

This works on most systems because we're copying zero bytes, but it is
technically undefined behavior to ever pass NULL to memcpy.

Even though c54980ab83 is where the bug manifests, that is only because
we switched away from a string_list, which is OK with being
zero-initialized (though it may cause other problems by not duplicating
the strings, it happened to be OK in this instance).

The actual bug is caused by the commit before that, 2a01bdedf8
(list-objects-filter: add and use initializers, 2022-09-11). There we
consistently initialize the top-level filter structs, but we forgot the
dynamically allocated ones we stick in filter_options->sub when creating
combined filters.

Note that we need to fix two spots here: where we parse a "combine:"
filter, but also where we transform from a single-filter into a combined
one after seeing multiple "--filter" options. In the second spot, we'll
do some minor refactoring to avoid repeating our very-long array index.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
list-objects-filter-options.c