NSNumberFormater test fails [Was: GNUstep Code Freeze]

[Fred Kiefer]

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 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 :-(

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.


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<address@hidden>  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<address@hidden>wrote:
> >
> > > On Sat, Jan 21, 2012 at 10:41 AM, Fred Kiefer<address@hidden>  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.

test_unum.c
Description: Text Data