When commit fe8e3b7 refactored type_from_string to allow input that was not NUL-terminated, it switched to using strncmp instead of strcmp. But this means we check only the first "len" bytes of the strings, and ignore any remaining bytes in the object_type_string. We should make sure that it is also "len" bytes, or else we would accept "comm" as "commit", and so forth.
Signed-off-by: Jeff King <peff@peff.net> --- Since the strings we are matching are literals, we could also record their sizes in the object_type_strings array and check the length first before even calling strncmp. I doubt this is a performance hot-spot, though.
You could also potentially just use strlen(object_type_strings[i]), but I'm not sure if compilers will optimize out the strlen in this case, since it is in a loop.
object.c | 3 ++- t/t1007-hash-object.sh | 8 ++++++++ 2 files changed, 10 insertions(+), 1 deletion(-)
Show changes to 2 files +10 −1
object.c, t/t1007-hash-object.sh
diff --git a/object.c b/object.c index 23d6c96..980ac5f 100644 --- a/object.c +++ b/object.c @@ -41,7 +41,8 @@ int type_from_string_gently(const char *str, ssize_t len, int gentle) len = strlen(str); for (i = 1; i < ARRAY_SIZE(object_type_strings); i++) - if (!strncmp(str, object_type_strings[i], len)) + if (!strncmp(str, object_type_strings[i], len) && + object_type_strings[i][len] == '\0') return i; if (gentle) diff --git a/t/t1007-hash-object.sh b/t/t1007-hash-object.sh index f83df8e..ebb3a69 100755 --- a/t/t1007-hash-object.sh +++ b/t/t1007-hash-object.sh @@ -201,4 +201,12 @@ test_expect_success 'corrupt tag' ' test_must_fail git hash-object -t tag --stdin </dev/null ' +test_expect_success 'hash-object complains about bogus type name' ' + test_must_fail git hash-object -t bogus --stdin </dev/null +' + +test_expect_success 'hash-object complains about truncated type name' ' + test_must_fail git hash-object -t bl --stdin </dev/null +' + test_done
-- 2.4.0.rc2.384.g7297a4a