On 6/26/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
Eric Covener wrote:
> On 6/25/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
>> * At run-time this should probably be determined by parsing first the
>> LC_CTYPE, or LC_ALL in it's absense, or the fallback to the LANG
>> envvar if neither LC_ variable is defined. The codepage follows
>> the period, e.g. LANG=en_US.UTF-8 would be parsed as 'UTF-8'.
>
> Wouldn't runtime checks would mean xlate/xlate.c needs to find a new
> way to figure out what the codepage of the source code was (to
> translate compiled-in strings)?
>
> Perhaps APR_DEFAULT_CHARSET could be split into two different
> identifiers APR_CURRENT_CHARSET/APR_BUILD_CHARSET that xlate callers
> would have to think about.
I'm confused. APR messages are all english (regrettably) in US-ASCII.
Taking that and massaging just a bit: APR strings in the source code
are either in US-ASCII or EBCDIC (simplifying just a bit on the
latter).
apr_os_default_encoding() needs to return something that can be passed
to apr_xlate_open() on the current platform in order to translate
compiled-in strings.
