[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: VS2005 issues (was 1.4.0-rc1 tarballs up for testing/signing)

From: Branko Čibej <brane_at_xbc.nu>
Date: 2006-06-10 01:35:05 CEST

D.J. Heap wrote:
> On 6/9/06, Branko Čibej <brane@xbc.nu> wrote:
> [snip]
>> > Actually, that was just the first problem. I do see the UTF-8 to
>> > CP437 xlate take place successfully and then fputs is called and dumps
>> > out ? instead of the special characters. I'll keep looking later, but
>> > I'm not really sure what to look for. Is CP437 the wrong code page?
>> CP437 is, for all intents and purposes, plain ASCII, which obviously
>> doesn't support any interesting characters. It this is a strict
>> (non-fuzzy) translation, then something is seriously wrong with
>> apr-iconv. If it's a fuzzy translation, then it's expected; IIRC that's
>> exactly what we do with untranslatable characters.
>>
>
>
> It's a strict translation, I think. After the xlate call
> (svn_cmdline_cstring_from_utf8 succeeds and so the fuzzy version isn't
> called) I see it as a 0x81, but it comes out as a ? on the console.
> The CP437 came from GetConsoleCP and GetConsoleOutputCP in
> svn_cmdline_init. And those are Win32 API's, so I'm not setting the
> language options correctly or something for Console apps?
You seem to have a very US-centric Windows installation without any
multilanguage support installed... 0x81 isn't a valid character in
CP437, IIRC, I wonder if apr_iconv thinks it's converting to CP850
(which is the "international ASCII", poor-man's DOS latin-1, sort of).
In that case, that's certainly a bug in apr-iconv.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 10 01:37:38 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.