user/sven/git.git/quote.c, branch v2.26.0-rc2

quote: use isalnum() to check for alphanumeric characters

2020-02-24T17:30:29Z

isalnum(c) is equivalent to isalpha(c) || isdigit(c), so use the former instead. The result is shorter, simpler and slightly more efficient. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

Merge branch 'gs/sq-quote-buf-pretty'

2019-10-15T04:48:02Z

Pretty-printed command line formatter (used in e.g. reporting the command being run by the tracing API) had a bug that lost an argument that is an empty string, which has been corrected. * gs/sq-quote-buf-pretty: sq_quote_buf_pretty: don't drop empty arguments

sq_quote_buf_pretty: don't drop empty arguments

2019-10-08T03:59:29Z

Empty arguments passed on the command line can be represented by a '', however sq_quote_buf_pretty was incorrectly dropping these arguments altogether. Fix this problem by ensuring that such arguments are emitted as '' instead. Signed-off-by: Garima Singh Signed-off-by: Junio C Hamano

quote: add sq_append_quote_argv_pretty()

2019-08-09T17:48:02Z

sq_quote_argv_pretty() builds a "pretty" string from the given argv. It inserts whitespace before each value, rather than just between them, so the resulting string always has a leading space. Lets give callers an option to not have the leading space or have to ltrim() it later. Create sq_append_quote_argv_pretty() to convert an argv into a pretty, quoted if necessary, string with space delimiters and without a leading space. Convert the existing sq_quote_argv_pretty() to use this new routine while preserving the leading space behavior. Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano

Indent code with TABs

2018-12-09T03:37:32Z

We indent with TABs and sometimes for fine alignment, TABs followed by spaces, but never all spaces (unless the indentation is less than 8 columns). Indenting with spaces slips through in some places. Fix them. Imported code and compat/ are left alone on purpose. The former should remain as close as upstream as possible. The latter pretty much has separate maintainers, it's up to them to decide. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Merge branch 'jk/sq-dequote-on-bogus-input'

2018-02-27T18:34:02Z

Code to unquote single-quoted string (used in the parser for configuration files, etc.) did not diagnose bogus input correctly and produced bogus results instead. * jk/sq-dequote-on-bogus-input: sq_dequote: fix extra consumption of source string

sq_dequote: fix extra consumption of source string

2018-02-14T19:11:49Z

This fixes a (probably harmless) parsing problem in sq_dequote_step(), in which we parse some bogus input incorrectly rather than complaining that it's bogus. Our shell-dequoting function is very strict: it can unquote everything generated by sq_quote(), but not arbitrary strings. In particular, it only allows characters outside of the single-quoted string if they are immediately backslashed and then the single-quoted string is resumed. So: 'foo'\''bar' is OK. But these are not: 'foo'\'bar 'foo'\' 'foo'\'\''bar' even though they are all valid shell. The parser has a funny corner case here. When we see a backslashed character, we keep incrementing the "src" pointer as we parse it. For a single sq_dequote() call, that's OK; our next step is to bail with an error, and we don't care where "src" points. But if we're parsing multiple strings with sq_dequote_to_argv(), then our next step is to see if the string is followed by whitespace. Because we erroneously incremented the "src" pointer, we don't barf on the bogus backslash that we skipped. Instead, we may find whitespace that immediately follows it, and continue as if all is well (skipping the backslashed character completely!). In practice, this shouldn't be a big deal. The input is bogus, and our sq_quote() would never generate this bogus input. In all but one callers, we are parsing input created by an earlier call to sq_quote(). That final case is "git shell", which parses shell-quoting generated by the client. And in that case we use the singular sq_quote(), which has always behaved correctly. One might also wonder if you could provoke a read past the end of the string. But the answer is no; we still parse character by character, and would never advance past a NUL. This patch implements the minimal fix, along with documenting the restriction (which confused at least me while reading the code). We should possibly consider being more liberal in accepting valid shell-quoted words. I suspect the code may actually be simpler, and it would be more friendly to anybody generating or editing input by hand. But I wanted to fix just the immediate bug in this patch. We don't have a direct way to unit-test the sq_dequote() functions, but we can do this by feeding input to GIT_CONFIG_PARAMETERS (which is not normally a user-facing interface, but serves here as it expects to see sq_quote() input from "git -c"). I've included both a bogus example, and a related "good" one to confirm that we still parse it correctly. Noticed-by: Michael Haggerty Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

trace: avoid unnecessary quoting

2018-01-16T20:16:54Z

Trace output which contains arbitrary strings (e.g., the arguments to commands which we are running) is always passed through sq_quote_buf(). That function always adds single-quotes, even if the output consists of vanilla characters. This can make the output a bit hard to read. Let's avoid the quoting if there are no characters which a shell would interpret. Trace output doesn't necessarily need to be shell-compatible, but: - the shell language is a good ballpark for what humans consider readable (well, humans versed in command line tools) - the run_command bits can be cut-and-pasted to a shell, and we'll keep that property - it covers any cases which would make the output visually ambiguous (e.g., embedded whitespace or quotes) Signed-off-by: Jeff King Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

sq_quote_argv: drop maxlen parameter

2018-01-16T20:16:54Z

No caller passes anything but "0" for this parameter, which requests that the function ignore it completely. In fact, in all of history there was only one such caller, and it went away in 7f51f8bc2b (alias: use run_command api to execute aliases, 2011-01-07). Signed-off-by: Jeff King Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

consistently use "fallthrough" comments in switches

2017-09-22T03:49:57Z

Gcc 7 adds -Wimplicit-fallthrough, which can warn when a switch case falls through to the next case. The general idea is that the compiler can't tell if this was intentional or not, so you should annotate any intentional fall-throughs as such, leaving it to complain about any unannotated ones. There's a GNU __attribute__ which can be used for annotation, but of course we'd have to #ifdef it away on non-gcc compilers. Gcc will also recognize specially-formatted comments, which matches our current practice. Let's extend that practice to all of the unannotated sites (which I did look over and verify that they were behaving as intended). Ideally in each case we'd actually give some reasons in the comment about why we're falling through, or what we're falling through to. And gcc does support that with -Wimplicit-fallthrough=2, which relaxes the comment pattern matching to anything that contains "fallthrough" (or a variety of spelling variants). However, this isn't the default for -Wimplicit-fallthrough, nor for -Wextra. In the name of simplicity, it's probably better for us to support the default level, which requires "fallthrough" to be the only thing in the comment (modulo some window dressing like "else" and some punctuation; see the gcc manual for the complete set of patterns). This patch suppresses all warnings due to -Wimplicit-fallthrough. We might eventually want to add that to the DEVELOPER Makefile knob, but we should probably wait until gcc 7 is more widely adopted (since earlier versions will complain about the unknown warning type). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano