Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Date: Wed, 4 Dec 2013 16:13:36 -0600
From: "William A. Rowe Jr." <wrowe@rowe-clan.net>
To: dev@apr.apache.org
Subject: Re: buffered files read after apr_file_close()'ed
Message-ID: <20131204161336.112193dc@hub>
In-Reply-To: <529DF0DD.8090606@myarm.com>
References: 
 <CALK=YjPWtRumFWeLm2-Bn1HUpQkGdfnFoDMyAmzRYcMDHk3ihg@mail.gmail.com>
 <529BD5B2.5070803@apache.org>
 <20131202173739.1ce0d204@hub>
 <529D9356.8080500@myarm.com>
 <CAKUrXK4ZQMOjJY2TOCmHeUZ=4_ec15Fowt1hV9tTdq5EDGC2HQ@mail.gmail.com>
 <529DDF84.4050703@myarm.com>
 <CAFE37chaD=k_T7bF=hJ3GntqmdR3GxXMZai2Dt8_WQ1-Pn5N9w@mail.gmail.com>
 <529DF0DD.8090606@myarm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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.