apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
Subject Re: Showstopper ... was: Tagged the tree
Date Thu, 09 Jan 2003 17:37:39 GMT
William A. Rowe, Jr. wrote:

>For something completely different, once this is released, we are stuck
>with the api...
>APR_DECLARE(apr_status_t) apr_filepath_encoding(int *style, apr_pool_t *p);
>Why not drop the enum and use an apr_filepath_encoding that returns
>an actual codepage name?  Then the ambiguity of _LOCALE disappears.
>Put another way, either APR_FILEPATH_ENCODING_LOCALE
>with a locale of utf-8 or the APR_FILEPATH_ENCODING_UTF8 can
>mean the same thing.  This seems wrong.
It's not. you get _UTF8 only when _UTF8 is _not_ the same as _LOCALE

>  For that matter, it might
>also be APR_FILEPATH_UNKNOWN if we didn't determine it.
I don't really expect any implementation fo apr_filepath_encoding to
return _UNKNOWN; it's there for completeness. If there is such an
implementation, it probably also can't implement apr_os_locale_encoding
and falls back on apr_os_default_encoding -- meaning "I don't know."

>Just asking for such things to be as clean as we can ask before we roll.

I spent much time and though (and discussion) wondering about this same
issue. I decided to do it this way because we already have functions
that return the name of the locale encoding, which apps can use if
necessary. An application really only has to know the difference between
_LOCALE and _UTF8, and convert accordingly; it doesn't necessarily have
to know the actual name of the encoding, so calling
apr_os_locale_encoding from apr_filepath_encoding is just a waste of
cycles, and so is "strcmp(foo,"UTF-8")" instead of

Brane ─îibej   <brane@xbc.nu>   http://www.xbc.nu/brane/

View raw message