Re: pread, pwrite, etc return ssize_t not int

On 01.03.24 22:23, Thomas Munro wrote:
>> For the overflow of the input length (size_t -> DWORD), I don't think we
>> actually need to do anything.  The size argument would be truncated, but
>> the callers would just repeat the calls with the remaining size, so in
>> effect they will read the data in chunks of rest + N * DWORD_MAX.  The
>> patch just changes this to chunks of N * 1GB + rest.
> 
> But implicit conversion size_t -> DWORD doesn't convert large numbers
> to DWORD_MAX, it just cuts off the high bits, and that might leave you
> with zero.  Zero has a special meaning (if we assume that kernel
> doesn't reject a zero size argument outright, I dunno): if returned by
> reads it indicates EOF, and if returned by writes a typical caller
> would either loop forever making no progress or (in some of our code)
> conjure up a fake ENOSPC.  Hence desire to impose a cap.

Right, my thinko.  Your patch is correct then.