Re: [PATCH] wt-status: Don't find scissors line beyond buf len

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 7, 2024, 19:35 UTC
Message-ID: <xmqqsf11ltrt.fsf@gitster.g>
In-Reply-To: <20240307183743.219951-1-flosch@nutanix.com>

Florian Schmidt <flosch@nutanix.com> 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 <buf, len> 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.