Re: [PATCH] Documentation: clarify whitespace rules for trailers

> > -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.