William A. Rowe, Jr. wrote:
>++1 if we can go with
>
>APR_DECLARE(apr_status_t) apr_filepath_list_split(
> apr_array_header_t **pathelts, const char *liststr, apr_pool_t *p);
>
>APR_DECLARE(apr_status_t) apr_filepath_list_merge(
> char **liststr, apr_array_header_t *pathelts, apr_pool_t *p);
>
I could definitely do that.
>Let's drop the 'env' concept - this is really useful overall.
>
>And please be careful to strip quotes from around elements, and add
>quotes (or on unix, backslash escape) the seperator element (e.g. colon
>or semicolon.)
>
Sure. I think we already have code that can do that, so I might want to
do a bit of refactoring.
>Sure the default docs can illustrate the typical
>
> apr_filepath_list_split(patharr, getenv("PATH"), p);
>
>but I think we want to stay away from overloading both getenv and split
>list facilities into a single function. It makes the API less useful :-)
>
This is where it stops working. On Windows, at least on NT-class
systems, you really do want to use the wide char functions to read the
environment and convert the result to UTF-8, otherwise we're not safe in
the presence of characters that can't be represented in the current
locale. I don't want to lose that capability, after all the trouble we
(you?) went to in the other I/O functions.
apr_filepath_getenv, maybe? (Put it in the apr_filepath namespace
because the value it returns is suitable for input into other apr_file*
functions.)
>Oh, you might plan for a flags element for options like APR_FILEPATH_NATIVE
>where we could even do colon, forward slashed paths by default and follow
>the platform convention when APR_FILEPATH_NATIVE is passed ;-)
>
Bah. We have apr_filepath_merge; there's no need to duplicate that
functionality, is there?
--
Brane Äibej <[EMAIL PROTECTED]> http://www.xbc.nu/brane/
