On 2011-09-27, at 11:53 PM, Paul Eggert wrote: > If I understand this patch correctly, it has an effect > only on hosts where SSIZE_MAX < INT_MAX. But there > are no such hosts in practice. So this patch addresses > only theoretical issues, right?
There are a couple of fixes in the patch: - The SSIZE_MAX fix pre-validates the read size and doesn't strictly have anything to do with INT_MAX, while the fix for Tru64 is a post-facto workaround. Since SUSv2 says the behaviour for reads larger than SSIZE_MAX (which happens to be the same as INT_MAX on 32-bit platforms) is undefined, it is better not to rely on read() returning EINVAL before switching to the smaller reads. On 64-bit platforms this check never does anything, since SSIZE_MAX is 2^63. - In case of SSIZE_MAX or BUGGY_READ_MAXIMUM, it continues to read into the buffer in smaller chunks until the read is completed. It seems to be a bug that BUGGY_READ_MAXIMUM internally truncates the read but didn't read as many bytes as requested. - This read continuation for BUGGY_READ_MAXIMUM and SSIZE_MAX also handles the short read() case that Kevin reported. That said, looking more closely at the rest of the code, I see that a function called full_rw() already exists that calls safe_rw() and handles the case of a short read that could be used directly instead of handling it at two levels. It looks like changing dump_regular_file(), sparse_dump_region(), and check_sparse_region(), check_data_region() to use full_read() instead of safe_read() would be enough. Cheers, Andreas
