A small nit with my own code :-)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Looking at this function:

APR_DECLARE(apr_status_t) apr_filepath_root(const char **rootpath, 
                                            const char **filepath, 
                                            apr_pool_t *p);

This function takes the given filepath and returns the pointer to a new (p alloc'ed)
rootpath, and adjusts filepath to the first relative element (eg /foo becomes a new
"/" rootpath string and filepath is offset, not copied, to the "foo" string.)

I originally copied the '/' root for unix into the pool.  I think that's overkill,
I should be able to return a const, shared "/" string, no?  For Win32 there is no
avoiding a new string allocated from p.

I also had several extra lines to code for Win32 since we return NULL for the
rootpath of a true relative path.  Any objections if this too was a const, shared
string of ""?

Notice that APR_EINCOMPLETE does return a rootpath (an incomplete one, at that) so
it seems to make more sense that APR_ERELATIVE would also return a string (empty).

Comments?

Bill

p.s. if you dug into the unix code already, I'm about to replace all root* variables
with base* variable names, so we have basepath and addpath.  This cleans up a huge
ambiguity when you cross into win32, with a baseroot, addroot, basepath and addpath.
rootroot got me laughing when I realized how convoluted it became :-)