On Wed, Sep 07, 2005 at 09:38:08AM +0100, Joe Orton wrote: > On Tue, Sep 06, 2005 at 09:49:12PM +0100, Colm MacCarthaigh wrote: > > It supports increasing and decreasing the buffer size, as well as making > > an unbuffered file handle buffered, and a buffered file unbuffered. > > > > The patch also adds a new subpool to the file handle, for the buffer > > itself, with the subpool being destroyed on buffer resizes. > > A subpool is an extra 8K of allocated memory for something the caller > might not need, I don't think this is a good idea.
It was only allocated if buffering was enabled, but I get what you mean. > I wonder if it would be better to simply allow the caller to choose and > manage the buffer allocation appropriately, a la stdio setbuf/setvbuf; > making the interface something like: > > apr_file_set_buffer(apr_file_t *file, char *buffer, apr_size_t buflen) It would still mean losing the original buffer, though I guess the application authors can have the sense to open the file un-buffered and then to use this call. > > Other things I'm thinking about; > > > > Destroying the subpool on apr_file_close, after all the lifetime > > of the buffer should be exactly concurrent with the lifetime of > > the file descriptor. > > > > Maybe making something like; > > > > apr_file_set_default_buffer_size(apr_off_t foo); > > insert "global state sucks" rant here :) (sizes of things in memory > should always be apr_size_t not apr_off_t btw) I know :) My reasoning for that is that to do with the bufpos handling. The bufpos itself is a plain "int", which won't ever overflow an apr_size_t, but then things like seek.c use an apr_off_t when they are assigning to bufpos. I wanted to avoid any overflow being my fault. Maybe I should I fix this too. bufpos should really be an apr_size_t and the handling should be consistent. -- Colm MacCárthaigh Public Key: [EMAIL PROTECTED]
