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



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to