> The interface seems to me to be intended to support partial writes (actual
> amount written returned in AMOUNT). Shouldn't it truncate?
If retrying with the remaining partial amount would be an error, than I
don't think it should. Returning a short write count usually indicates you
can write
On Mon, Mar 11, 2002 at 06:09:16PM -0500, Roland McGrath wrote:
> > Because in this case store_next_run is called, and store_next_run wraps
> > around, this will succeed.
>
> That should not happen. It should not be wrapping around at all for most
> stores. I suspect that what's needed is an en
On Mon, Mar 11, 2002 at 11:36:56PM +0100, Marcus Brinkmann wrote:
> and, yo and behold, the calculation of maxaddr will underflow, leading to a
^^^
maxread
> maxaddr of around 2^32 minus something (something being 256kb - 566 or so).
^^^
maxread
> Because the size of the first run is smaller than that, store_read tries
> to read from multiple stores.
You mean multiple runs.
> Because in this case store_next_run is called, and store_next_run wraps
> around, this will succeed.
That should not happen. It should not be wrapping around at
Hi,
I figured out what's wrong with the gunzip store.
The compressed file is 566 bytes. Now, zread in gunzip() in gunzip.c does
try to read in chunks of 256kb (IN_BUFFERING). This means, store_read is
called with amount being 256kb. Because the size of the first run is
smaller than that, stor
