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.
