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 :-)
