apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
Subject Re: Misbehaviour of apr_os_locale_encoding on Windows
Date Tue, 13 Apr 2010 18:34:21 GMT
On 13.04.2010 19:19, William A. Rowe Jr. wrote:
> On 4/13/2010 12:00 PM, Branko ─îibej wrote:
>> Well no, but ... as a matter of fact, most of the locale stuff in
>> Subversion on Windows, starting with command-line parsing (we don't use
>> apr_app_initialize) all the way to printing to the console (we don't use
>> the wide-character printf variants) is subtly wrong. And on my head be
>> it because I implemented all those bits and know about the deficiencies
>> and haven't fixed it.
> FWIW, not using apr_app_initialize will significantly restrict what non-ASCII
> paths are going to do, since the filesystem is handled in utf-8, and likely
> collects many operating variables from the env array and command line args.

Yes, I know ... lazyness on my part.

> Fortunately we have several win32, non-roman-charset folks around to show up
> where these flaws could hide and help diagnose.
> But the majority of the subversion issues described here are in subversion.


> What is your opinion of the proposed patch to just this interface?  It seems
> that aligning to the system LCID is very problematic for a multi-user OS,
> where you are on an eastern European codepage, and I'm on a western codepage.
> The files you are working with are likely different than mine.  Changing to
> the systemwide codepage definitely seems invalid, notwithstanding the issues
> noted about apr_user_name_get().

I really have no clue offhand. It seems wrong to ignore the thread
locale in all cases. Like I wrote in the other post, this picking of one
of the 55 different current locales can probably only be properly done
by the application, not by APR. Which would imply that either APR should
expose some of those alternate locales through its API (eek!) or we
gently dump this whole issue as a Somebody Else's Problem.

-- Brane

View raw message