Srujith A Poojary submitted an Outreachy patch replacing manual multiplication and addition in create_delta_index() with st_mult, st_add and st_add3, intended to prevent overflow while keeping NULL returns on failure. Phillip Wood noted that clang-format suggested alignment fixes and asked about the bounds of hsize and whether adding one to it could overflow.
Junio C Hamano replied that hsize is capped early in the function, making hsize + 1 safe, but that this needs to be explained in the log message. The second version of the patch added that note. It also said that on 32-bit platforms, struct alignment padding could push the total allocation size past 2^32.
Hamano then did his own calculation and reached a different conclusion on the padding claim. He worked through the sizes: entries capped by roughly 2^32/16, hsize capped at 2^26, a 4-byte hash element and a 16-byte entry if padded. By that count, 4 * 2^26 + 16 * 2^28 could overflow if the struct has padding and would fit if it does not. He acknowledged that his math is probably weaker than he would like.
Srujith later said that since entries is capped by (0xffffffu / RABIN_WINDOW), hsize stays small and a size_t overflow is impossible even on 32-bit systems. Hamano responded that he should not claim that without first checking whether it can overflow. He quoted the cap on entries and the hsize computation and said it may not be possible to overflow size_t even on 32-bit platforms, but that he had not yet had time to do the math himself.
The commit message's justification is therefore unsettled, with the patch's claim and the author's later statement pointing in opposite directions and no reviewer yet confirming either.