Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of iain.wade@gmail.com
 designates 64.233.178.241 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=PdsBDzyw3shei7nCsvhoqcbOe6s4Ol4ipuPjOAJZdALuAMzfx4OQrQL4/HNLH0yJ8Q4N9xKOWR5dMymY5NVNcBnNJJ+qxHAU5NhEOcTaq/dFMfAUaCwmeYCRvpzYe1IUpq8mak0F+kRn4mfOBzt0w5k61MuZxQKwRiJi2EnjRVs=
Message-ID: <d4833ecd0712122056s68a488d3g4d146713555d90eb@mail.gmail.com>
Date: Thu, 13 Dec 2007 15:56:02 +1100
From: "Iain Wade" <iwade@optusnet.com.au>
Sender: iain.wade@gmail.com
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: apr_os_dir_put fixes
Cc: "Lucian Adrian Grijincu" <lucian.grijincu@gmail.com>,
	"Michael Clark" <michael@metaparadigm.com>, dev@apr.apache.org
In-Reply-To: <4760B801.6030007@rowe-clan.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <d4833ecd0712110524o5be3a386u3c9628dc4e8842b8@mail.gmail.com>
	 <475E944F.3030707@rowe-clan.net>
	 <acf3f2e60712110742r451ffcek3980b14ace05c01f@mail.gmail.com>
	 <475EB4A8.8030409@metaparadigm.com>
	 <475EB8A1.5090702@metaparadigm.com>
	 <acf3f2e60712110832o3dec6352o52333a3da3416627@mail.gmail.com>
	 <d4833ecd0712122035s7d0f72e5kc4d03fe28f9cf1fb@mail.gmail.com>
	 <4760B801.6030007@rowe-clan.net>

> > 2/ Create a new apr_os_file_put_ex function, which adds a register_cleanup flag.
>
> Why a bool?  We already pass a flags arg, why not a toggle bit?

I know what you mean, I was torn in adding the bool myself but chose to because:

I note that apr_os_pipe_put_ex already exists with a register_cleanup bool.

APR_FILE_NOCLEANUP is actually APR_FOPEN_NOCLEANUP which doesn't seem
correctly named for a non-open case.

If I depended on the existing flag, maintaining existing behavior of
apr_os_file_put would be tough.

The apr_*dir* functions don't accept flags yet, and if I add one then
the dir function would take a different flag - confusing.

> Interesting, I'll need to review this a bit.  Perhaps that should be broken
> out as a seperate patch, and 1 and 3 considered together, 2 considered on it's
> own (in conjunction with 1).

Sure, I'll get them over shortly.

--Iain