From 753c8101b027f34359a921a8acb3abe7f10058c5 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Thu, 19 Mar 2026 00:15:59 -0700 Subject: [PATCH 1/2] rerere: update to modern representation of empty strbufs Back when b4833a2c (rerere: Fix use of an empty strbuf.buf, 2007-09-26) was written, a freshly initialized empty strbuf had NULL in its .buf member, with .len set to 0. The code this patch touches in rerere.c was written to _fix_ the original code that assumed that the .buf member is always pointing at a NUL-terminated string, even for an empty string, which did not hold back then. That changed in b315c5c0 (strbuf change: be sure ->buf is never ever NULL., 2007-09-27), and it has again become safe to assume that .buf is never NULL, and .buf[0] has '\0' for an empty string (i.e., a strbuf with its .len member set to 0). A funny thing is, this piece of code has been moved around from builtin-rerere.c to rerere.c and also adjusted for updates to the hash function API over the years, but nobody bothered to question if this special casing for an empty strbuf was still necessary: b4833a2c62 (rerere: Fix use of an empty strbuf.buf, 2007-09-26) 5b2fd95606 (rerere: Separate libgit and builtin functions, 2008-07-09) 9126f0091f (fix openssl headers conflicting with custom SHA1 implementations, 2008-10-01) c0f16f8e14 (rerere: factor out handle_conflict function, 2018-08-05) 0d7c419a94 (rerere: convert to use the_hash_algo, 2018-10-15) 0578f1e66a (global: adapt callers to use generic hash context helpers, 2025-01-31) Finally get rid of the special casing that was unnecessary for the last 19 years. Signed-off-by: Junio C Hamano --- rerere.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/rerere.c b/rerere.c index 3cd37c5f0a..6e0c218332 100644 --- a/rerere.c +++ b/rerere.c @@ -402,12 +402,8 @@ static int handle_conflict(struct strbuf *out, struct rerere_io *io, strbuf_addbuf(out, &two); rerere_strbuf_putconflict(out, '>', marker_size); if (ctx) { - git_hash_update(ctx, one.buf ? - one.buf : "", - one.len + 1); - git_hash_update(ctx, two.buf ? - two.buf : "", - two.len + 1); + git_hash_update(ctx, one.buf, one.len + 1); + git_hash_update(ctx, two.buf, two.len + 1); } break; } else if (hunk == RR_SIDE_1) From f64c50e76827f39c843102bc603817648a38a48c Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Thu, 19 Mar 2026 15:39:02 -0700 Subject: [PATCH 2/2] cocci: strbuf.buf is never NULL We recently noticed one old code from 19 years ago protecting against an ancient strbuf convention that the .buf member can be NULL for an empty strbuf. As that is no longer the case in the modern codebase, let's catch such a construct. Signed-off-by: Junio C Hamano --- contrib/coccinelle/strbuf.cocci | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/contrib/coccinelle/strbuf.cocci b/contrib/coccinelle/strbuf.cocci index 5f06105df6..13f0ad2679 100644 --- a/contrib/coccinelle/strbuf.cocci +++ b/contrib/coccinelle/strbuf.cocci @@ -60,3 +60,10 @@ expression E1, E2; @@ - strbuf_addstr(E1, real_path(E2)); + strbuf_add_real_path(E1, E2); + +// In modern codebase, .buf member of an empty strbuf is not NULL. +@@ +struct strbuf SB; +@@ +- SB.buf ? SB.buf : "" ++ SB.buf