apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
Subject Re: [PATCH] Determining the character encoding used for paths in APR
Date Fri, 19 Jul 2002 06:33:44 GMT
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   <brane@xbc.nu>   http://www.xbc.nu/brane/

View raw message