Thanks, everyone, for looking into this.
On 04/01/2017 09:18 PM, Jeff King wrote:
On Sat, Apr 01, 2017 at 12:03:44PM -0700, Linus Torvalds wrote:
The logic is fairly simple: if we encounter an empty line, and we have
pending in-body headers, we flush the pending headers, and mark us as
no longer in header mode.
Hmm. I think this may work. At first I thought it was too strict in
always checking inbody_header_accum.len, because we want this to kick in
always, whether there's whitespace continuation or not. But that
accumulator has to collect preemptively, before it knows if there's
continuation. So it will always be non-empty if we've seen _any_ header,
and it will remain non-empty as long as we keep parsing (because any
time we flush, we do so in order to handle another line).
IOW, I think this implements the state-machine thing I wrote in my
earlier email, because the state "are we inside in-body header parsing"
is always reflected by having a non-empty accumulator. It is a bit
non-obvious though.
About obviousness, I think of a non-empty accumulator merely
representing that the next line could potentially be a continuation
line. And it is coincidence that this implies "are we inside in-body
header parsing"; if not all in-body header lines could be "continued",
there would be no such implication.
mi->inbody_header_accum.len is already used in check_inbody_header to
mean "could the next line potentially be a continuation line" and to
trigger a check for a negative criterion (in this case, a scissors
line). I think it's fine to do the same thing, the negative criterion
here being a blank line.
