Nathan Hartman <hartman.nat...@gmail.com> writes: > Is it possible and does it make sense to always continue reading until > EOF, when the read is either 0 or < 16k? In other words to eliminate > the comparison against the expanded size?
I believe setting the expanded size correctly is the only fix we need. > Alternatively, if reading up to the expanded size and then stopping, > does it make sense to attempt another read, which must come back as 0, > to verify that the expanded size and actual size are equal? If not > equal, an error message on this issue would be far more helpful than > the one currently output. Not sure. The caller often does just that but that essentially just involves: if (rb->off == rb->len) *len = 0; and trivially returns 0. I suppose we could make a call to data extraction functions but I don't know how that would behave. I am reluctant to do it on a release branch. There is one additional check we should add, on trunk at least. This code was originally written as a read_fn for an svn_stream_t and thus had to allow short reads. It is now a read_full_fn and the only short read is at EOF, so we should verify the expanded size on a short read. > Have you had a chance to test against the 1.10 rc? The trunk/1.10 code has been reworked and, as far as I can tell, the bug is not present. -- Philip