[Lldb-commits] [PATCH] D25783: [Host] handle short reads and writes

[Zachary Turner via lldb-commits]

zturner added a comment.

In https://reviews.llvm.org/D25783#574860, @labath wrote:

> > This can happen with any number of bytes and at any time.  `write`, `read`, and all other related functions will return a non-negative value indicating the number of bytes successfully read/written, which will be less than the number requested.
>
> Except if fd refers to a pipe, in which case writes of up to PIPE_MAX will be atomic.
>
> Also, I just noticed another problem. What if the fd does not refer to an actual file, but a non-seekable file system object (named pipe, domain socket, ...). Will the lseek work on that? I have no idea. But, I think you're implementing a broken API to save a couple of lines of code.


In that case the user should be using `Host/Pipe` or a more suitable class, this class is already unsuitable just on the grounds that it exposes a method (the offset version) that requires a seekable device.  I'd even be fine asserting in the constructor if the device is not seekable.

> (btw, you may want to know that pwrite() on O_APPEND descriptors basically ignores the offset argument, and always does an append).

Only on Linux, but this is apparently non-conformant behavior :(

https://linux.die.net/man/2/pwrite

> POSIX requires that opening a file with the O_APPEND flag should have no affect on the location at which pwrite() writes data. However, on Linux, if a file is opened with O_APPEND, pwrite() appends data to the end of the file, regardless of the value of offset.

IDK, I'm the Windows guy so this isn't really my call, but I think part of the reason why the test suite is so flaky and bugs are so hard to track down sometimes is because we don't make assumptions.  If we find some code that is clearly broken without a given set of assumptions, I think making it break "even more" without those assumptions is not only fine, but even desirable so that problems become easier to track down.


https://reviews.llvm.org/D25783