William A. Rowe, Jr. wrote: >For something completely different, once this is released, we are stuck >with the api... > >#define APR_FILEPATH_ENCODING_UNKNOWN 0 >#define APR_FILEPATH_ENCODING_LOCALE 1 >#define APR_FILEPATH_ENCODING_UTF8 2 >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 (foo==APR_FILEPATH_ENCODING_UTF8). -- Brane Čibej <[EMAIL PROTECTED]> http://www.xbc.nu/brane/
