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

[Junio C Hamano <gitster@pobox.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.