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.