Nathan Hartman <[email protected]> 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
