add_pending_object_with_path(): work around "gcc -O3" complaint
commit1d72b604ef638155f7af91c968ccf1c95234ecee
authorJeff King <peff@peff.net>
Thu, 10 Jun 2021 13:06:43 +0000 (10 09:06 -0400)
committerJunio C Hamano <gitster@pobox.com>
Fri, 11 Jun 2021 03:45:37 +0000 (11 12:45 +0900)
tree37f370fc616a7f69012d174d3c31ce0dc61db5b9
parentebf3c04b262aa27fbb97f8a0156c2347fecafafb
add_pending_object_with_path(): work around "gcc -O3" complaint

When compiling with -O3, some gcc versions (10.2.1 here) complain about
an out-of-bounds subscript:

  revision.c: In function ‘do_add_index_objects_to_pending’:
  revision.c:321:22: error: array subscript [1, 2147483647] is outside array bounds of ‘char[1]’ [-Werror=array-bounds]
    321 |   if (0 < len && name[len] && buf.len)
        |                  ~~~~^~~~~

The "len" parameter here comes from calling interpret_branch_name(),
which intends to return the number of characters of "name" it parsed.

But the compiler doesn't realize this. It knows the size of the empty
string "name" passed in from do_add_index_objects_to_pending(), but it
has no clue that the "len" we get back will be constrained to "0" in
that case.

And I don't think the warning is telling us about some subtle or clever
bug. The implementation of interpret_branch_name() is in another file
entirely, and the compiler can't see it (you can even verify there is no
clever LTO going on by replacing it with "return 0" and still getting
the warning).

We can work around this by replacing our "did we hit the trailing NUL"
subscript dereference with a length check. We do not even have to pay
the cost for an extra strlen(), as we can pass our new length into
interpret_branch_name(), which was converting our "0" into a call to
strlen() anyway.

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