D.J. Heap wrote:
> On 6/9/06, D.J. Heap <djheap@gmail.com> wrote:
> [snip]
>>
>> So, VC6 fputs pays attention to locale and VC2005 fputs doesn't? Does
>> it sound correct that the different locales affect the output
>> language?
>
>
> After tracing deeper into this, it looks like the opposite is true and
> why things break with VC2005 -- VC2005 fputs is translating to the
> console CP for us. Since we already did it once, it is
> double-translating and turning special characters into ?'s. If I
> comment out the code in svn_cmdline_init that sets the input/output
> encodings, then it works fine.
Ah. A light begins to shine.
> So...is that code to determine console CP and do input/output
> encodings ourselves due to broken locale handling on VC6? Because it
> appears we don't need it (and it breaks things when present) in
> VC2005...how is it supposed to work on unix since we don't seem to do
> any special encoding there -- does the CRT handle it?
On Unix, the native encoding and the output encoding are always the
same. On Windows, the native (multi-byte) encoding is an "ANSI" code
page, whilst the console output encoding is (usually, by default) an OEM
encoding (that is, one that DOS would've understood ... yikes). So, on a
US installation, you'd get CP1252 as the native multi-byte encoding, and
CP437 on the console. Where I live, that combination would be
CP1250/CP852. In most of Western Europe, it would be CP1252/CP850. And
so on.
So it seems that Microsoft, in its wisdom, having screwed this up
originally by carrying DOS compatibility just a bit too far, have
screwed up again by silently changing that behaviour. Or rather, since
Windows behaves as it always has, they've "helped" developers by making
the runtime library "smarter".
What this means for us is that the bit in svn_cmdline_init that you
commented out must be conditionally compiled based on the compiler
version (_MSC_VER macro). For VS2005, I believe that's 1300.
There is another option, of course -- although it will take longer to
implement -- and that is to always use the wide-character functions for
output on Windows (wputs, etc.). That's doable now that we've changed
most (all?) output-producing code in the client to use the
svn_cmdline_printf class of functions. We'd have to check what happens
with redirected output, though -- I think it should be automagically
converted to multi-byte, but you never know ...
In any case, I'd recommend trying the "#if _MSC_VER < 1300" first, as
that's a trivial change and should fix the problem.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 11 15:45:09 2006