From: Junio C Hamano Date: Thu, 07 Mar 2024 19:35:34 GMT Subject: Re: [PATCH] wt-status: Don't find scissors line beyond buf len Message-ID: In-Reply-To: <20240307183743.219951-1-flosch@nutanix.com> Florian Schmidt writes: > Side remark: Since strstr() doesn't consider len, and will always search > up to a null byte, I now wonder whether it would be safer to create a > new strbuf that only contains the len bytes we want to operate on. That is a valid concern in general, but does not seem to apply to the current codebase. Thanks for being careful. Two of the three callers of wt_status_locate_end() feed the pointer into a piece of memory that is owned by strbuf, which guarantees that the memory has an extra NUL to terminate it as a string even if you did strbuf buf = STRBUF_INIT; strbuf_addch(&buf, 'A'); The other one is in commit.c:ignored_log_message_bytes() that still takes as input, but again, two of its three callers call it with a pointer that points at the beginning of memory held by an instance of strbuf. That leaves us trailer.c:find_end_of_log_message() the only one to worry about, but it uses strlen() on the pointer before calling ignored_log_message_bytes() so the region of the memory pointed at by the pointer is assumed to be NUL-terminated already, and presumably (I didn't follow the logic there too closely) the length is also computed within that NUL-terminated string.