On Fri, Nov 25, 2011 at 04:43:41PM +0100, Henrik Grubbström wrote: > On Wed, 23 Nov 2011, Henrik Grubbström wrote: > > >Hi. > > > >My git repository walker just got bitten by what seems to be a > >reasonably new bug in convert.c:cascade_filter_fn() (git 1.7.8.rc3 > >(gentoo)). > > After some tracing, the problem is triggered by the variable "remaining" > being set to 1 in the beginning of the cascade_filter_fn() loop, > which causes filter "two" to be called with an output buffer size of > 1. > Filter "two" in this case is lf_to_crlf_filter_fn(), and the next > input character is a "\n". lf_to_crlf_filter_fn() wants to convert > this to "\r\n", but that doesn't fit into the buffer, so it breaks > out and returns zero. Upon seing the zero cascade_filter_fn() thinks > all is well, even though nothing has happened, and loops. > > The bug is probably that lf_to_crlf_filter_fn() should return > non-zero in this case (ie o and/or i being zero). non-zero? That would cause the filter to abort, which definitely not what we want. Have you seen my other e-mails regarding this? I'm trying to figure out which is the best way to go about this. The solution is to keep track of the fact that we're missing a LF in the output buffer. cmn
Attachment:
signature.asc
Description: Digital signature