Re: Bug in reflog of length 0x2BFF

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 4, 2014, 22:14 UTC
Message-ID: <xmqq388vrrj9.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20141204215805.GD19953@peff.net>

Jeff King <peff@peff.net> writes:

Show 6 quoted lines

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

Show 8 quoted lines

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