apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From br...@xbc.nu
Subject Re: [PATCH] Determining the character encoding used for paths in APR
Date Fri, 19 Jul 2002 18:43:55 GMT
Quoting "William A. Rowe, Jr." <wrowe@rowe-clan.net>:

> At 10:29 AM 7/19/2002, Karl Fogel wrote:
> >Branko Ä&#65533;ibej <brane@xbc.nu> writes:
> > > Anyway, the intent here is to tell the user what the APR
> > > _implementation_ knows about the path encoding. On most platforms,
> > > 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.
> On Windows, we will only utf-8 on WinNT, on the Win9x family we will
> have
> to return the local code page.

Exactly. That's just what the patch does.

> > > We need opinions from lots of Unix people here. Folks, don't be shy!
> :-)
> >
> >:-)
> >
> >+1, and I think I prefer the simplicity of Brane's original
> >implementation.
> >
> >In fact, I wonder if we couldn't do it *entirely* with macros, since
> >the function call just compiles down to a single return statement
> >anyway.  Why not avoid the function call overhead entirely?
> On Win32, we need to a function to return based on platform.
> But I must be missing something ... 

Yes :-)

> where do we intend to pick
> up the local code page values from on Win9x and other, more
> obscure unices that don't simply follow the locale construct?

Let me say again: The intent of this function is _not_ to return the actual
encoding. It's intent is to tell you how to _find_ the encoding, so that you can
use apr_xlate correctly on the paths.

The use case is:
    switch (apr_filepath_encoding())
        cvt = apr_xlate_open(APR_LOCALE_CHARSET, "foo");
        cvt = apr_xlate_open("UTF-8", "foo");
        /* What to do? Reeling, writhing and fainting in coils
           might be appropriate. */;

> I'd really like Jeff Trawick's feedback on this, given his expsoure
> to the many ebcdic-based boxes.  If we implement this at all,
> I'd like to avoid a half-assed approach and return something useful,
> such as determine the local charset used for the filesystem across
> all platforms.  Otherwise this is YAWH [yet another Win32 hack].

No, it't not.

Um, O.K., I concede there's another way to do this.... We'll need
apr_os_locale_charset() and apr_os_default_charset() in APR anyway, because
apr_xlate needs them. In that case, this function can really return the actual
charset identifier.

View raw message