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.
