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

Re: [TSVN] Problem with source encoding in TortoiseSVN 1.2

From: Norbert Unterberg <nepo_at_gmx.net>
Date: 2005-06-16 19:34:28 CEST

SteveKing schrieb:

> Well, since we set the locale to the default locale, we should use
> LC_ALL here.

I just wanted to mention the risk because I once did set LC_ALL in one
of our applications, and from that moment it failed reading floating
point values with sscanf in "computer" format (12.5 vs. 12,5).

> I was surprised that MFC didn't do that on its own, because when using
> the CStdioFile.ReadLine() MFC calls the _fgetss() function - which
> didn't work correctly in UNICODE builds because the locale wasn't even
> set!

I guess it did not work for UTF8 files? Because UTF-8 does not seem to
be supported by any microsoft library...
I think that setting/enabling locale settings should remain a choice of
the developer. If you do not set the locale, then the code uses the
default "C" locale which means no conversion is performed, and the
library is compatible with "old" K&R C. I guess that's why no locale is
set by default. How many percent of developers know about locales anyway?

> SetThreadLocale() isn't necessary - it is always set to the default
> when an application starts or a new thread is created.

I know, it was just to complete the list ... you know, you used to set
the ThreadLocale to some other language once in a while without noticing
the side effects in some eastern languages ... ;-)

Norbert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Jun 16 19:35:39 2005

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

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