William A. Rowe, Jr. wrote:
Before we consider this patch, there is a deeper question.
Will we support MULTIPLE paths? If so we should consider a given filepath as an argument to the function. I'm thinking unix or NFS mounts here, not really win32 filesystems since NT is utf-8 and others are local codepages.
I don't think you _can_ determine the actual encoding for paths on NFS mounts. Anyone?
That said, adding a path argument wouldn't hurt -- even though you'd have to pass in a pool, too, for completeness. :-)
How about:
apr_status_t apr_filepath_encoding (apr_filepath_encoding_e *encoding,
const char* path, apr_pool_t *pool);
It looks like overkill to me, though ... -0.
Finally, I would rather return an apr_xlate compatible string, not some enum that must be extended forever.
You'd have to include apr_xlate.h to get APR_LOCALE_CHARSET and APR_DEFAULT_CHARSET, but that file is in APR-util now. I don't want to move those constants back into APR.
Anyway, the intent here is to tell the user what the APR _implementation_ knows about the path encoding. On most platforms, APR doesn't do anything with the paths, so we know that information can be pulled from the locale. On Windows, we know when we'll return UTF-8, regardless of locale. The enum would only grow if we started doing something radically different in a port to a new system.
We need opinions from lots of Unix people here. Folks, don't be shy! :-)
-- Brane Äibej <[EMAIL PROTECTED]> http://www.xbc.nu/brane/
