Re: NSNumberFormatter tests fix

[Fred Kiefer]

Now this is interesting. Why is this the case and how does this code
behave on MacOSX? If it is only on GNUstep that the order in which we
use two independent operations is important, then we should rather fix
our code and not our tests.

Am 04.03.2011 09:06, schrieb Philippe Roussel:
> One of the tests in basic.m (round up for fractional part >0.5) is
> failing only because of code ordering. The appended patch fixes it.
> 
> Philippe
> 
> Index: base/NSNumberFormatter/basic.m
> ===================================================================
> --- base/NSNumberFormatter/basic.m    (revision 32445)
> +++ base/NSNumberFormatter/basic.m    (working copy)
> @@ -15,16 +15,14 @@
>                   "+[NSNumberFormatter alloc] returns a NSNumberFormatter");
>  
>    fmt = [[[NSNumberFormatter alloc] init] autorelease];
> -  num = [[[NSNumber alloc] initWithFloat: 1234.567] autorelease];
>  
> -  str = [fmt stringForObjectValue: num];
> -
> -  PASS_EQUAL(str, @"1,234.57", "default format same as Cocoa");
> -
>    num = [[[NSNumber alloc] initWithFloat: 1.01] autorelease];
>    PASS_EQUAL([fmt stringFromNumber: num], @"1.01",
>      "Handle leading zeroes in fractional part: 1.01");
>  
> +  num = [[[NSNumber alloc] initWithFloat: 1234.567] autorelease];
> +  str = [fmt stringForObjectValue: num];
> +  PASS_EQUAL(str, @"1,234.57", "default format same as Cocoa");
>  
>    [fmt setAllowsFloats: NO];
>    PASS_EQUAL([fmt stringForObjectValue: num], @"1,235",