Florian Schmidt <flosch@xxxxxxxxxxx> 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.
