apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: buffered files read after apr_file_close()'ed
Date Wed, 04 Dec 2013 22:13:36 GMT
On Tue, 03 Dec 2013 15:55:25 +0100
Stefan Ruppert <sr@myarm.com> 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.



Mime
View raw message