Subject: Re: Bug in reflog of length 0x2BFF

From: Junio C Hamano <[email-masked]>
Date: Thu, 04 Dec 2014 14:14:50 -0800

Jeff King <[email-masked]> writes:

> I think the bug is in the reverse-reflog reader in
> for_each_reflog_ent_reverse. It reads BUFSIZ chunks of the file in
> reverse order, and then parses them individually. If the trailing
> newline for a line falls directly on the block boundary, we may not have
> it in our current block, and pass the line to show_one_reflog_ent
> without a trailing newline.

Ahh, thanks for helping spot it.  A code that uses BUFSIZ explains
why a single reproduction recipe is platform dependent.

> So this is a long-standing bug in for_each_reflog_ent_reverse. It just
> showed up recently because we started using that function for
> read_ref_at_ent.
> ...
> The above is a workaround. I think the right solution is probably to
> teach for_each_reflog_ent_reverse to makes sure the trailing newline is
> included (either by tweaking the reverse code, or conditionally adding
> it to the parsed buffer).

Sounds correct.  Unfortunately I no longer remember how I decided to
deal with a line that spans the block boundary in that piece of code
X-<.