On Tue, 03 Dec 2013 15:55:25 +0100 Stefan Ruppert <[email protected]> wrote:
> Am 03.12.2013 15:15, schrieb Daniel Lescohier: > > > However, the functions still need to change to return errors for the > > cases when they are unbuffered files. The buffer won't be > > referenced (and cause a crash) in those cases. > > But in this case the OS will return an EBADF if read() or write() is > called. Correct, provided we've set fd = -1 (in case a new file has been opened with the prior fd assignment). On windows, INVALID_HANDLE value would accomplish the same thing, while NULL'ing out the mutex will avoid the reported issue, and we can simply toggle a buffered file to false to cause i/o to occur (and fail). This adds three assignment ops to the close operation, and no cpu ops to all the common read/write/test cases, which is the best all-around solution IMHO. The reason to solve, following Brane's initial comments, is that as our devs live on Windows, or Linux, or OS/X or wherever, that things should try and fail in a somewhat consistent manner, to let those persistent devs track down their bugs.
