git/strbuf.c, branch v2.45.2

don't report vsnprintf(3) error as bug

2024-04-21T19:27:07Z

strbuf_addf() has been reporting a negative return value of vsnprintf(3) as a bug since f141bd804d (Handle broken vsnprintf implementations in strbuf, 2007-11-13). Other functions copied that behavior: 7b03c89ebd (add xsnprintf helper function, 2015-09-24) 5ef264dbdb (strbuf.c: add `strbuf_insertf()` and `strbuf_vinsertf()`, 2019-02-25) 8d25663d70 (mem-pool: add mem_pool_strfmt(), 2024-02-25) However, vsnprintf(3) can legitimately return a negative value if the formatted output would be longer than INT_MAX. Stop accusing it of being broken and just report the fact that formatting failed. Suggested-by: Jeff King Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

Merge branch 'jk/core-comment-string'

2024-04-05T17:49:49Z

core.commentChar used to be limited to a single byte, but has been updated to allow an arbitrary multi-byte sequence. * jk/core-comment-string: config: add core.commentString config: allow multi-byte core.commentChar environment: drop comment_line_char compatibility macro wt-status: drop custom comment-char stringification sequencer: handle multi-byte comment characters when writing todo list find multi-byte comment chars in unterminated buffers find multi-byte comment chars in NUL-terminated strings prefer comment_line_str to comment_line_char for printing strbuf: accept a comment string for strbuf_add_commented_lines() strbuf: accept a comment string for strbuf_commented_addf() strbuf: accept a comment string for strbuf_stripspace() environment: store comment_line_char as a string strbuf: avoid shadowing global comment_line_char name commit: refactor base-case of adjust_comment_line_char() strbuf: avoid static variables in strbuf_add_commented_lines() strbuf: simplify comment-handling in add_lines() helper config: forbid newline as core.commentChar

factor out strbuf_expand_bad_format()

2024-03-25T18:59:24Z

Extract a function for reporting placeholders that are not enclosed in a parenthesis or are unknown. This reduces the number of strings to translate and improves consistency across commands. Call it at the end of the if/else chain, after exhausting all accepted possibilities. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

find multi-byte comment chars in unterminated buffers

2024-03-12T20:28:10Z

As with the previous patch, we need to swap out single-byte matching for something like starts_with() to match all bytes of a multi-byte comment character. But for cases where the buffer is not NUL-terminated (and we instead have an explicit size or end pointer), it's not safe to use starts_with(), as it might walk off the end of the buffer. Let's introduce a new starts_with_mem() that does the same thing but also accepts the length of the "haystack" str and makes sure not to walk past it. Note that in most cases the existing code did not need a length check at all, since it was written in a way that knew we had at least one byte available (and that was all we checked). So I had to read each one to find the appropriate bounds. The one exception is sequencer.c's add_commented_lines(), where we can actually get rid of the length check. Just like starts_with(), our starts_with_mem() handles an empty haystack variable by not matching (assuming a non-empty prefix). A few notes on the implementation of starts_with_mem(): - it would be equally correct to take an "end" pointer (and indeed, many of the callers have this and have to subtract to come up with the length). I think taking a ptr/size combo is a more usual interface for our codebase, though, and has the added benefit that the function signature makes it harder to mix up the three parameters. - we could obviously build starts_with() on top of this by passing strlen(str) as the length. But it's possible that starts_with() is a relatively hot code path, and it should not pay that penalty (it can generally return an answer proportional to the size of the prefix, not the whole string). - it naively feels like xstrncmpz() should be able to do the same thing, but that's not quite true. If you pass the length of the haystack buffer, then strncmp() finds that a shorter prefix string is "less than" than the haystack, even if the haystack starts with the prefix. If you pass the length of the prefix, then you risk reading past the end of the haystack if it is shorter than the prefix. So I think we really do need a new function. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strbuf: accept a comment string for strbuf_add_commented_lines()

2024-03-12T20:28:10Z

As part of our transition to multi-byte comment characters, let's take a NUL-terminated string pointer for strbuf_add_commented_lines() rather than a single character. All of the callers have to be adjusted; most can just pass comment_line_str rather than comment_line_char. And now our "cheat" in strbuf_commented_addf() can go away, as we can take the full string from it. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strbuf: accept a comment string for strbuf_commented_addf()

2024-03-12T20:28:10Z

As part of our transition to multi-byte comment characters, let's take a NUL-terminated string pointer for strbuf_commented_addf() rather than a single character. All of the callers have to be adjusted, but they can just pass comment_line_str rather than comment_line_char. Note that we rely on strbuf_add_commented_lines() under the hood, so we'll cheat a bit to squeeze our string into a single character (for now the two are equivalent, and we'll address this TODO in the next patch). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strbuf: accept a comment string for strbuf_stripspace()

2024-03-12T20:28:10Z

As part of our transition to multi-byte comment characters, let's take a NUL-terminated string pointer for strbuf_stripspace(), rather than a single character. We can continue to support its feature of ignoring comments by accepting a NULL pointer (as opposed to the current behavior of a NUL byte). All of the callers have to be adjusted, but they can all just pass comment_line_str (or NULL). Inside the function we detect comments by comparing the first byte of a line to the comment character. We'll adjust that to use starts_with(), which will match multiple bytes (though for now, of course, we still only allow a single byte, so it's academic). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strbuf: avoid shadowing global comment_line_char name

2024-03-12T20:28:10Z

Several comment-related strbuf functions take a comment_line_char parameter. There's also a global comment_line_char variable, which is closely related (most callers pass it in as this parameter). Let's avoid shadowing the global name. This makes it more obvious that we're not using the global value, and it will be especially helpful as we refactor the global in future patches (in particular, any macro trickery wouldn't work because the preprocessor doesn't respect scope). We'll use "comment_prefix". That should be descriptive enough, and as a bonus is more neutral with respect to the "char" type (since we'll eventually swap it out for a string). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strbuf: avoid static variables in strbuf_add_commented_lines()

2024-03-12T20:28:09Z

In strbuf_add_commented_lines(), we have to convert the single-byte comment_line_char into a string to pass to add_lines(). We cache the created string using a static-local variable. But this makes the function non-reentrant, and it's doubtful that this provides any real performance benefit given that we know the string always contains a single character. So let's just create it from scratch each time, and to give the compiler the maximal opportunity to make it fast we'll ditch the over-complicated xsnprintf() and just assign directly into the array. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strbuf: simplify comment-handling in add_lines() helper

2024-03-12T20:28:09Z

In strbuf_add_commented_lines(), we prepare two strings with potential prefixes: one with just the comment char, and one with an additional space. In the add_lines() helper, we use the one without the extra space for blank lines or lines starting with a tab. While passing in two separate prefixes to the helper is very flexible, it's more flexibility than we actually use (or are likely to use, since the rules inside add_lines() only make sense if "prefix2" is a variant of "prefix1" without the extra space). And setting up the two strings makes refactoring in strbuf_add_commented_lines() awkward. Instead, let's pass in a single string, and just let add_lines() add the extra space to the result as appropriate. We do still need to pass in a flag to trigger this behavior. The helper is shared by strbuf_add_lines(), which passes in a NULL "prefix2" to inhibit this extra handling. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano