Yann Ylavic <ylavic....@gmail.com> writes: > But the short-write argument stands, if Windows never short-writes > then the implicit full-write is unnecessary, but if it does > short-write then apr_file_write() has to return it too (for the user > to know), so in both cases the loop has to stop when written < > to_write (and probably return success if written > 0). > Users that don't expect short-writes should use apr_file_write_full().
As far as I recall, I had an intent of not changing the behavior more than necessary, as the original code was always making a full write. I agree that we could potentially allow for short writes when performing the passthrough part of the write that makes its way around the buffer. But all in all, I think that we might want to keep the current approach, because: — This won't change the actual behavior for Win32 files from a practical standpoint, because synchronous WriteFile() guarantees a full write for them. — There's a tricky case where we need to handle a large write with len > DWORD_MAX. I think that we might want to not handle it with a short write, because if we do so, we're going to have an actually reproducible short write for files (i.e., different behavior) in the rare edge case. — Flushing the buffer requires a full write, so at least a part of the buffered apr_file_write() is still going to do a full write. Regards, Evgeny Kotkov
