Whilst I didn't ever meet a problem caused by this, I spotted a possible flaw in
apr_os_locale_encoding() as shown in the following part:

--- 
APR_DECLARE(const char*) apr_os_locale_encoding (apr_pool_t *pool)
{
#if defined(HAVE_NL_LANGINFO) && defined(CODESET)
    const char *charset;

    charset = nl_langinfo(CODESET);
    if (charset && *charset) {
#ifdef _OSD_POSIX /* Bug workaround - delete as soon as fixed in OSD_POSIX */
        /* Some versions of OSD_POSIX return nl_langinfo(CODESET)="^[nN]" */
        /* Ignore the bogus information and use apr_os_default_encoding() */
        if (charset[0] != '^')
#endif
        return charset;
    }
#endif

    return apr_os_default_encoding(pool);
}
--- 

As stated in the nl_langinfo() spec
(http://www.opengroup.org/onlinepubs/009695399/functions/nl_langinfo.html ), the
pointer returned by nl_langinfo() may be transient and subject to race
conditions as well, so it's better off duplicating it instead of returning the
original one.

HTH,
Moriyoshi