Hi,
I just had a look in to this problem. While it sounds like there is certainly a 
bug in libicu - it should not break if the libc locale is changed - I am very 
skeptical that setting the libc locale as we do in +[NSObject initialize] (or 
anywhere else... IIRC it's also done in NSUserDefaults) is a good idea.

Just to recap, +[NSObject initialize] does setlocale(LC_ALL, ""); which reads 
the current locale from the LANG environment variable (and others)[1] and sets 
all of the libc locale settings to that locale - so after +[NSObject 
initiazlize], printf("%g", 1.23) will output "1,23" if your system locale is 
French, for example.

My main problem with this is, I don't think any shared library really has the 
right to change this setting… if an application/tool wanted to switch from the 
default C locale to the current system locale, that should be the application's 
decision, since it has global consequences for everything running in that 
process (changing the semantics of printf!). But there would hardly be a point 
to doing that because GNUstep provides more powerful formatting anyway 
(NSNumberFormatter, etc.)

>  The "official" way of setting the locale in ICU is using uloc_setDefault()

According to the ICU docs, the notion of locale in ICU is totally independent 
of libc's. For number formatting, the ICU default locale only has an effect if 
you pass NULL for the locale when calling unum_open.

So setting the libc locale should have no effect on ICU's default locale (not 
true because of the bug mentioned below), and vice-versa - setting the ICU 
locale has no effect on the system locale.

Eric

[1] actually more complicated, at least for glibc: 
http://www.gnu.org/software/libc/manual/html_mono/libc.html#Locale-Categories

On 2012-01-23, at 6:43 AM, Stefan Bidi wrote:

> On Mon, Jan 23, 2012 at 3:01 AM, Fred Kiefer <fredkie...@gmx.de> wrote:
> That bug description is not accurate. When running the NSNumberformatter test 
> program we only call setlocale() twice, once with "" and once with NULL as 
> the locale. That would be supported behaviour according to the bug 
> description, but clearly it is not.
> 
> I'll attach that modified version to the bug report.
> 
> I changed your test program to call setlocale() and now it also reports NaN 
> (See attachment). This really makes me wonder whether it is such a great idea 
> to use an internationalisation library that only supports English :-(
> 
> In all fairness, it has been classified as bug in the library.  The 
> "official" way of setting the locale in ICU is using uloc_setDefault().  To 
> get the locale it's uloc_getDefault().  But I see your point and am a little 
> surprised that this is even an issue.  I'm even more surprised that it keeps 
> getting pushed off to a later release.  It seems to have originally been 
> scheduled for 4.6, then 4.8 and now 5.0.
>  
> BTW: Is there a reason why the macro STRING_FROM_NUMBER calls the conversion 
> twice, even when it was successful on the first attempt? I don't like the use 
> of macros that much it really makes it hard to tell what is going on and code 
> in macros never gets as much review as normal code.
> 
> No, it's wrong.  I saw that when mucking around in there, too, but didn't a 
> fix commit (I'll do so when I get home, today).  Don't ask me how I managed 
> to screw that up... I don't know either.
> 
> On 21.01.2012 23:00, Stefan Bidi wrote:
> After running a few more tests and still not understanding what is going on
> I went to good and found this bug report:
> http://bugs.icu-project.org/trac/ticket/8214
> 
> Seems that ICU does not like it when we use setlocale().
> 
> On Sat, Jan 21, 2012 at 1:53 PM, Stefan Bidi<stefanb...@gmail.com>  wrote:
> 
> I am completely baffled by this bug.  I've been trying to debug this for
> the last 3 hrs and have gotten absolutely no where.  I added a unum_open
> and unum_formatDouble call in -init and I still get NaN when
> LANG=de_DE.UTF-8.  The test program continues to work without a hitch,
> though.  Something about how we handle the NSNumberFormatterInternal
> structure is screwing up UNumberFormat (I also added a unum_open and
> unum_formatDouble call in basic10_4.m and it worked fine).
> 
> 
> On Sat, Jan 21, 2012 at 11:00 AM, Stefan Bidi<stefanb...@gmail.com>wrote:
> 
> On Sat, Jan 21, 2012 at 10:41 AM, Fred Kiefer<fredkie...@gmx.de>  wrote:
> 
> Your test code works fine here and results in 1.234 as expected. My
> $LANG is de_DE.UTF-8. And with $LANG set to C the test run fine.
> Strange enough currentLocale ends up being en_US_POSIX
> 
> 
> -currentLocale looks for a Locale default, if it exists that's what it
> uses.  Do you have that set?
> 
> This still wouldn't explain why UNumberFormat is returning NaN.  Both you
> and Philippe have a valid locale.  On the plus side, if I set
> LANG=de_DE.UTF-8 I can reproduce this.  I'll go try to figure out what's
> going on.
> 
> _______________________________________________
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Reply via email to