On Wed, Aug 24, 2022 at 8:13 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Christian Couder <christian.couder@xxxxxxxxx> writes: > > -When reading trailers, there can be whitespaces after the > > -token, the separator and the value. There can also be whitespaces > > -inside the token and the value. The value may be split over multiple lines with > > -each subsequent line starting with whitespace, like the "folding" in RFC 822. > > +When reading trailers, there can be no whitespace inside the token, > > +and only one regular space or tab character between the token and the > > +separator. > > That may have been the intent, but does it match the behaviour? > > static ssize_t find_separator(const char *line, const char *separators) > { > int whitespace_found = 0; > const char *c; > for (c = line; *c; c++) { > if (strchr(separators, *c)) > return c - line; > if (!whitespace_found && (isalnum(*c) || *c == '-')) > continue; > if (c != line && (*c == ' ' || *c == '\t')) { > whitespace_found = 1; > continue; > } > break; > } > return -1; > } > > When parsing "X :", first we encounter 'X', we haven't seen > whitespace, 'X' passes isalnum(), and we continue. Then we > encounter ' ', we haven't seen whitespace but it is neither isalnum > or dash, so we go on without hitting the first continue. We are not > at the beginning of the line, we are seeing a space, so we remember > the fact that we saw whitespace and continue. Next we see another ' ', > we do not hit the first continue, we are not at the beginning of the > line, and we are looking at ' ', so we again continue. Finally, we see > ':' that is a separator and we return happily. > > The code seems to be allowing zero or more space/tab before the > separator. Yeah, I agree. I misread the code. I will send a new version soon. Thanks.