On Wed, Jan 12, 2011 at 03:29:45PM +0100, "Plüm, Rüdiger, VF-Group" wrote: > > In that case the correct behaviour of the input filter is to return a > > partial read with APR_SUCCESS (per AP_MODE_GETLINE semantics > > described > > in util_filter.h). So the data must *not* also be buffered in that > > case, and the behaviour was correct before. > > I guess the second call to char_buffer_write can happen in the situation > you describe above, but IMHO it can also happen if we have a non blocking read > and we just did not get enough data.
How? If no LF is ever found the loop continues until the buffer is full with tmplen == 0. In the case of read failure/EAGAIN, the code returns from the function early and never falls out of the loop. (This is all non-obvious because of the structure of the code; it might read more clearly if the if (pos) bit was moved inside the loop before the break.) Regards, Joe
